summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-07-24Bump to 1.01.0sin
2018-07-24Don't use __extension__ in C++ codeA. Wilcox
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
2017-08-22Bump to 0.90.9sin
2017-08-22Don't trap if an encoding error occurs in wcrtomb()sin
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>
2016-09-10Bump copyright yearsin
2016-07-14Bump to 0.80.8sin
2016-07-14Only include limits.h when actually usedNatanael Copa
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>
2015-07-24Bump to 0.70.7sin
2015-07-16Only crash on overflow for realpath()sin
2015-07-15Fix stpncpy() checksin
Do not crash unless the overflow would happen.
2015-07-15Fix confstr() checksin
Do not crash unless the overflow would actually happen.
2015-07-15Fix wcrtomb() checksin
This was breaking valid code, example: char c; wcrtomb(&c, L'0', st);
2015-06-25Add __extension__ mark to include_next to silence -pedanticSteven Barth
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-22unistd: fix signed / unsigned comparison in getgroupsSteven Barth
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-17Bump to 0.60.6sin
2015-06-04Use the __inline__ keyword instead of __inline to avoid breakageTrutz Behn
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-03Use namespace-safe macro, param and variable namesTrutz Behn
2015-06-03Fix usage of __USER_LABEL_PREFIX__Trutz Behn
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-05-29Bump to 0.50.5sin
2015-05-21Fix return-type of fortified FD_CLR and FD_SETTrutz Behn
POSIX specifies them to have return-type void, not int.
2015-05-19Be less verbose in READMEsin
2015-05-13Wrap some overly long linessin
2015-05-13Add LICENSE headersin
2015-05-13Add fortify_fn() helper in fortify-headers.hsin
2015-05-07Minor style fixsin
2015-05-07fix realpath when stdlib.h is included before limits.hNatanael Copa
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-04-08Add read checks for bcopy()sin
2015-04-08Check for out of bound reads for memcpy, memmove and mempcpy()sin
2015-04-06Bump to 0.40.4sin
2015-04-01Update README againsin
2015-04-01Update READMEsin
2015-04-01Add feature-test guards for mbsnrtowcs() and wcsnrtombs()sin
2015-03-24Update READMEsin
2015-03-24Add url to alpine linux fortify integrationsin
2015-03-16Bump to 0.30.3sin
2015-03-15Hide stpcpy() and stpncpy() under feature test macrossin
2015-03-14Use __typeof__ to in part avoid replicating function typesTrutz Behn
2015-03-14Fix typo in attribute nameTrutz Behn
2015-03-14Update the READMEsin
__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-14Explicitly cast pointers to satisfy C++ codesin
2015-03-14Add __artificial__ to aid in debuggingsin
2015-03-13Restore C++ supportsin
2015-03-13Fix typo againsin
2015-03-13Implement snprintf() and sprintf() using __builtin_va_arg_pack()sin
Requires at least GCC 4.3.
2015-03-13Re-order vsnprintf() and vsprintf()sin
vsprintf() needs to access __vsnprintf_orig().
2015-03-13Fix typosin
2015-03-13Rework fortify implementation to use extern inlinesin
Overriding functions with macros is legal in C but a lot of software is not prepared for it. Use the extern inline method to achieve the same result.
2015-03-11Put include guards in the reserved namespaceTrutz Behn
fortify-headers is considered part of the implementation.
2015-03-11Clarify what is meant by not supporting C++sin
2015-03-11Add note about C++ in the READMEsin