fortify-headers, branch 1.1

Bump to 1.1

2019-04-14T08:25:54Z

getgroups: do not trap on non-positive gidsetsize

2019-03-13T17:47:50Z

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.

wctomb, wcrtomb: guard slow/trap path with MB_LEN_MAX

2019-03-07T00:05:34Z

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).

realpath: guard slow/trap path with PATH_MAX

2019-03-07T00:05:30Z

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.

Bump copyright

2019-02-25T13:22:33Z

Make use of builtins whenever possible

2019-02-25T13:17:08Z

Bump to 1.0

2018-07-24T10:01:30Z

Don't use extension in C++ code

2018-07-24T10:00:30Z

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 . 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

Bump to 0.9

2017-08-22T10:38:57Z

Don't trap if an encoding error occurs in wcrtomb()

2017-08-22T10:38:36Z

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