| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
LLVM libcxx (20.1.8) also defines a `__format` macro in it's
C++ locale header (`/usr/include/c++/v1/locale`).
Fixes: https://github.com/jvoisin/fortify-headers/issues/76
|
|
|
|
|
|
|
|
Fixes https://github.com/jvoisin/fortify-headers/issues/31
|
|
Co-Authored-By: jvoisin <julien.voisin@dustri.org>
|
|
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.
|
|
|
|
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.
|
|
|
|
The predefined __USER_LABEL_PREFIX__ macro if it is non-empty contains
an identifier, not a string literal, thus it needs to be stringified.
|
|
|
|
|
