fortify-headers/include/sys, branch 0.8

Add extension mark to include_next to silence -pedantic

2015-06-25T09:18:26Z

Signed-off-by: Steven Barth

Use the inline keyword instead of __inline to avoid breakage

2015-06-04T17:52:50Z

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 names

2015-06-03T17:55:35Z

Fix return-type of fortified FD_CLR and FD_SET

2015-05-21T09:10:17Z

POSIX specifies them to have return-type void, not int.

Add LICENSE header

2015-05-13T11:15:36Z

Add fortify_fn() helper in fortify-headers.h

2015-05-13T11:05:29Z

Use typeof to in part avoid replicating function types

2015-03-14T20:37:27Z

Add artificial to aid in debugging

2015-03-14T09:38:22Z

Restore C++ support

2015-03-13T23:09:15Z

Rework fortify implementation to use extern inline

2015-03-13T11:00:46Z

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.