Commit Graph

170 Commits

Author SHA1 Message Date
sin e3fee64643 Bump to 1.1 2019-04-14 09:25:54 +01:00
info@mobile-stream.com 9e65ae387c getgroups: do not trap on non-positive gidsetsize
First, we should never check the size of __s if __l == 0 since the
array is not going to be modified in that case.

Second, negative __l is a well-defined error case (EINVAL) and we
should never trap on a conforming code like this:

r = getgroups(-1, NULL);
if (r == -1)
  ...

An example of non-desired behaviour for negative __l is the gnulib
configure script which checks for getgroups(-1, ...) to catch some
ancient FreeBSD kernel bug. The conftest binary traps even on good
system (e.g. linux/musl) and the unnecessary getgroups wrapper is
enforced for any project that uses gnulib.

This patch also changes the size_t cast to avoid the explicit zero
extension on systems where size_t differs from unsigned int.
2019-03-13 17:47:50 +00:00
info@mobile-stream.com 9b796691eb wctomb, wcrtomb: guard slow/trap path with MB_LEN_MAX
This allows the compiler to optimize out the slow/trap path at all
for the typical correct code:

char buf[MB_LEN_MAX];
r = wctomb(buf, c);

The change tries to keep the "unknown object size" case handling in
wcrtomb() as is even if it seems redundant and not helping (we copy
__buf to possibly undersized __s in any case) and inconsistent with
wctomb() (where we let the original library method itself overwrite
the possibly undersized __s).
2019-03-07 00:05:34 +00:00
info@mobile-stream.com ff82ffbc74 realpath: guard slow/trap path with PATH_MAX
This allows the compiler to optimize out the slow/trap path at all
for the typical correct code:

char buf[PATH_MAX];
r = realpath(path, buf);

The change keeps the "unknown object size" case handling intact.
2019-03-07 00:05:30 +00:00
sin 1435d8186b Bump copyright 2019-02-25 13:22:33 +00:00
sin 5aabc7e6aa Make use of builtins whenever possible 2019-02-25 13:17:08 +00:00
sin ad9a6d93b7 Bump to 1.0 2018-07-24 11:01:30 +01:00
A. Wilcox a9ffac8596 Don't use __extension__ in C++ code
A few important notes:

*  __extension__ is a GNU C "alternate" keyword, not a C++ keyword.[1]

*  __extension__ is designed to work on "expressions"; it does work on
   #include_next in C mode, but it has no effect in C++ mode; the
   warning will still appear, if enabled, even with __extension__
   preceding #include_next.  This is because #include_next is not
   considered an expression in C++, so the compiler attaches
   __extension__ to the first expression of the header.

All of this leads us to a build failure while building at least all
Mozilla software.  Moz has an alternate -isystem dir searched before
/usr/include that overrides some headers, including <features.h>.  The
first statement in each of these headers is a #pragma, and since
__extension__ is looking for an expression, and #pragma is a "null"
expression, we end up with the following error:

dist/system_wrappers/features.h:1:9: error: '#pragma' is not allowed here

Since __extension__ has no effect on #include_next in C++ mode anyway,
and since it can cause breakage, this commit omits __extension__ in C++
mode.

[1]: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Alternate-Keywords.html
2018-07-24 11:00:30 +01:00
sin 6e7e43ff99 Bump to 0.9 2017-08-22 11:38:57 +01:00
sin 9730e9d297 Don't trap if an encoding error occurs in wcrtomb()
The POSIX definition of wcrtomb
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/wcrtomb.html)
states:

"When wc is not a valid wide character, an encoding error shall occur.
In this case, the function shall store the value of the macro [EILSEQ]
in errno and shall return (size_t)-1; the conversion state shall be
undefined."

The fortify-headers implementation of wcrtomb interprets the result -1
as 18446744073709551615 bytes. Since this is the highest 64-bit number
possible, it is pretty safe to say this will always be larger than any
buffer provided to wcrtomb. Therefore, it traps.

Fixes bug https://bugs.alpinelinux.org/issues/7681.

Patch by A. Wilcox <AWilcox@Wilcox-Tech.com>
2017-08-22 11:38:36 +01:00
sin 2bc423c355 Bump copyright year 2016-09-10 12:54:17 +01:00
sin ee2b986235 Bump to 0.8 2016-07-14 16:09:32 +01:00
Natanael Copa 9880d5864b Only include limits.h when actually used
The __extension__ seems to trigger a bug in gcc when there are no
identifier specified afterwards.

Testcase:
  echo "#include <stdlib.h>" > try.c && cc -O0 -c try.c
  try.c:2:0: error: expected identifier or '(' at end of input

With -O2 it does not happen.

We work around this by only pulling in limits.h when we actually need the
PATH_MAX.

Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
2016-07-14 16:09:13 +01:00
sin 578b693300 Bump to 0.7 2015-07-24 14:29:06 +01:00
sin 60dcebb6b8 Only crash on overflow for realpath() 2015-07-16 11:45:19 +01:00
sin edb2ded3af Fix stpncpy() check
Do not crash unless the overflow would happen.
2015-07-15 17:02:27 +01:00
sin a51406af12 Fix confstr() check
Do not crash unless the overflow would actually happen.
2015-07-15 16:05:52 +01:00
sin a255506ca4 Fix wcrtomb() check
This was breaking valid code, example:
char c;
wcrtomb(&c, L'0', st);
2015-07-15 15:55:56 +01:00
Steven Barth 7fd984fcb5 Add __extension__ mark to include_next to silence -pedantic
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-25 10:18:26 +01:00
Steven Barth 0825063aa6 unistd: fix signed / unsigned comparison in getgroups
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-22 19:05:54 +01:00
sin 8ff214efe6 Bump to 0.6 2015-06-17 16:37:56 +01:00
Trutz Behn 4cdac9cbda Use the __inline__ keyword instead of __inline to avoid breakage
Newer compilers default to GNU11, a C11 dialect. Some software however
is unprepared for this or has wrong compatibility checks. What happens
is that some software will for compatibility with C89

  #define inline

before inclusion of a standard header, which is undefined behaviour in
C99 and above (C99/C11 7.1.2/4), as inline is a keyword.

If any libc headers that are then included via #include_next provide an
__inline macro definition (current musl does this if C++ or C99 and
above is detected) like the following

  #define __inline inline

this results in any __inline token to be preprocessed away.

This breaks use of __builtin_va_arg_pack() in our stdio.h at
compile-time as it can only be used in always inlined functions. The
function attributes __always_inline__ and __gnu_inline__ themselves
require an inline specifier on the function to be applied.
2015-06-04 18:52:50 +01:00
Trutz Behn 1cd5461a53 Use namespace-safe macro, param and variable names 2015-06-03 18:55:35 +01:00
Trutz Behn a9ee1d2743 Fix usage of __USER_LABEL_PREFIX__
The predefined __USER_LABEL_PREFIX__ macro if it is non-empty contains
an identifier, not a string literal, thus it needs to be stringified.
2015-06-03 08:33:32 +01:00
sin ec970ecb88 Bump to 0.5 2015-05-29 12:38:17 +01:00
Trutz Behn 720c4f7414 Fix return-type of fortified FD_CLR and FD_SET
POSIX specifies them to have return-type void, not int.
2015-05-21 10:10:17 +01:00
sin a81e053a1c Be less verbose in README 2015-05-19 10:22:59 +01:00
sin 50e37c7f76 Wrap some overly long lines 2015-05-13 12:18:35 +01:00
sin 07adb50914 Add LICENSE header 2015-05-13 12:15:36 +01:00
sin 158782b3bb Add fortify_fn() helper in fortify-headers.h 2015-05-13 12:05:29 +01:00
sin 316a486533 Minor style fix 2015-05-07 18:04:01 +01:00
Natanael Copa c2bb9e106a fix realpath when stdlib.h is included before limits.h
If program includes stdlib.h before limits.h without _XOPEN_SOURCE,
_GNU_SOURCE or _BSD_SOURCE explicitly set, then will it always trigger
the trap with musl libc.

This is becase stdlib.h will pull in features.h which will set
_GNU_SOURCE. This means that the fortify stdlib.h will not include
limits.h but it will still trigger the fortified realpath(), but without
PATH_MAX set.

We fix this by including system stdlib.h before testing if limits.h
should be included.

Since PATH_MAX is known at compile time we can also error at compile
time, instead of compiling a broken realpath().
2015-05-07 15:02:11 +01:00
sin c7e82d4863 Add read checks for bcopy() 2015-04-08 15:25:47 +01:00
sin 2bd3091b36 Check for out of bound reads for memcpy, memmove and mempcpy() 2015-04-08 15:18:49 +01:00
sin 91a579a42c Bump to 0.4 2015-04-06 10:06:01 +01:00
sin 534ef92103 Update README again 2015-04-01 17:49:31 +01:00
sin e359fc6ace Update README 2015-04-01 17:46:57 +01:00
sin 73839e34a6 Add feature-test guards for mbsnrtowcs() and wcsnrtombs() 2015-04-01 12:41:08 +01:00
sin 739ec00a02 Update README 2015-03-24 12:25:13 +00:00
sin d6510c1594 Add url to alpine linux fortify integration 2015-03-24 12:24:17 +00:00
sin 19e34402d5 Bump to 0.3 2015-03-16 12:02:16 +00:00
sin 442a2a4d65 Hide stpcpy() and stpncpy() under feature test macros 2015-03-15 09:57:26 +00:00
Trutz Behn 22e7e51007 Use __typeof__ to in part avoid replicating function types 2015-03-14 20:37:27 +00:00
Trutz Behn c2c9d0c6c8 Fix typo in attribute name 2015-03-14 19:39:14 +00:00
sin 9419492998 Update the README
__builtin_va_arg_pack() is not present in clang along with some
other things like __artificial__ etc.

There will be a fallback mechanism for this implemented in the
next release.
2015-03-14 11:11:04 +00:00
sin 0932a82ada Explicitly cast pointers to satisfy C++ code 2015-03-14 09:45:37 +00:00
sin 37eb2c9c1d Add __artificial__ to aid in debugging 2015-03-14 09:38:22 +00:00
sin d12254166a Restore C++ support 2015-03-13 23:09:15 +00:00
sin c4abf4497b Fix typo again 2015-03-13 17:14:58 +00:00
sin c8ecc164f1 Implement snprintf() and sprintf() using __builtin_va_arg_pack()
Requires at least GCC 4.3.
2015-03-13 17:03:52 +00:00