fortify-headers/include, branch 0.6Standalone portable header-based implementation of FORTIFY_SOURCE=3
http://git.dustri.org/fortify-headers/atom?h=0.62015-06-04T17:52:50ZUse the __inline__ keyword instead of __inline to avoid breakage2015-06-04T17:52:50ZTrutz Behn2015-06-04T13:01:37Zurn:sha1:4cdac9cbdaa01f884e0e8b3f947b7f0cb1170729
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.
Use namespace-safe macro, param and variable names2015-06-03T17:55:35ZTrutz Behn2015-06-03T17:27:01Zurn:sha1:1cd5461a5375207602f2cbdfd9a50a9b751cb7c8Fix usage of __USER_LABEL_PREFIX__2015-06-03T07:33:32ZTrutz Behn2015-06-02T19:33:39Zurn:sha1:a9ee1d2743acb0b2903db87c0a241c0a569cfc4e
The predefined __USER_LABEL_PREFIX__ macro if it is non-empty contains
an identifier, not a string literal, thus it needs to be stringified.
Fix return-type of fortified FD_CLR and FD_SET2015-05-21T09:10:17ZTrutz Behn2015-05-20T20:09:46Zurn:sha1:720c4f7414c3c3d980de8e6ddbc0f608d3e9050d
POSIX specifies them to have return-type void, not int.
Wrap some overly long lines2015-05-13T11:18:35Zsin2015-05-13T11:18:35Zurn:sha1:50e37c7f766ba94f42993e14bb3207807ff14b30Add LICENSE header2015-05-13T11:15:36Zsin2015-05-13T11:15:36Zurn:sha1:07adb509146e4185b9b7587baad26cdfb766c67eAdd fortify_fn() helper in fortify-headers.h2015-05-13T11:05:29Zsin2015-05-13T11:04:15Zurn:sha1:158782b3bb791eae3c97947944c7023452bfbc96Minor style fix2015-05-07T17:04:01Zsin2015-05-07T17:04:01Zurn:sha1:316a48653315b4bc36d8c50b542471b18441c9d5fix realpath when stdlib.h is included before limits.h2015-05-07T14:02:11ZNatanael Copa2015-05-07T12:50:03Zurn:sha1:c2bb9e106a32619726cfc5052a1509e96b90de9f
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().
Add read checks for bcopy()2015-04-08T14:25:47Zsin2015-04-08T14:25:47Zurn:sha1:c7e82d4863992c2f3bbb6f5a31fa8e5fd0e1643f