| Age | Commit message (Collapse) | Author |
|---|
|
This fixes invalid conversion errors when the fd_set is defined as
const.
fixes https://github.com/jvoisin/fortify-headers/issues/66
|
|
|
|
|
|
This should fix #32
|
|
This is unlikely to be used, since fd_set is
usually manipulated by macros, but it doesn't hurt
to add a simple comparison.
|
|
|
|
- Remove a superfluous `#if defined(__has_builtin)` since it's already
accounted for in include/fortify-headers.h
- Replace `_FORTIFY_FD_POS0` with the already existing `_FORTIFY_POS0`
- Factorise some duplicate code into a macro
|
|
|
|
|
|
|
|
It seems useless and triggers 'error: expected external declaration'
|
|
GCC and Clang provide __builtin_dynamic_object_size
(see documentation: https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html),
so we should make use of it when its available.
|
|
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
|
|
|
|
Signed-off-by: Steven Barth <steven@midlink.org>
|
|
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.
|
|
|
|
POSIX specifies them to have return-type void, not int.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
fortify-headers is considered part of the implementation.
|
|
It is not legal to override standard functions using macros in C++.
We may have to revisit this in the future.
|
|
|
|
|
|
|
|
These can produce false positives. Given that we support fortify
source level 1 we shouldn't break valid code.
|
|
|
|
Thanks zhasha for spotting this.
|
|
|
|
|
|
|
|
|
|
|
