fortify-headers, branch 0.9

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

Bump copyright year

2016-09-10T11:54:17Z

Bump to 0.8

2016-07-14T15:09:32Z

Only include limits.h when actually used

2016-07-14T15:09:13Z

The __extension__ seems to trigger a bug in gcc when there are no identifier specified afterwards. Testcase: echo "#include " > 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

Bump to 0.7

2015-07-24T13:29:06Z

Only crash on overflow for realpath()

2015-07-16T10:45:19Z

Fix stpncpy() check

2015-07-15T16:02:27Z

Do not crash unless the overflow would happen.

Fix confstr() check

2015-07-15T15:05:52Z

Do not crash unless the overflow would actually happen.

Fix wcrtomb() check

2015-07-15T14:55:56Z

This was breaking valid code, example: char c; wcrtomb(&c, L'0', st);