fortify-headers/include/sys/select.h, branch add_old_gcc

Fix compilation under clang

2026-03-13T00:11:32Z

Makes uses of _FORTIFY_INLINE and _FORTIFY_POS0 in sys/select.h, as clang complains about __gnu_inline__ in some cases. An issue which is already fixed with the shared macros. It was reported it: - https://gitlab.alpinelinux.org/alpine/aports/-/issues/18015 - https://gitlab.alpinelinux.org/alpine/aports/-/issues/18000 Co-Authored-By: Sertonix

Add missing include in select.h

2025-11-10T22:55:25Z

add initial clang support

2025-10-31T21:16:21Z

Co-Authored-By: jvoisin

avoid extension with clang

2025-10-31T21:16:21Z

It seems useless and triggers 'error: expected external declaration'

Make use of __builtin_dynamic_object_size

2025-10-31T21:16:21Z

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.

Don't use extension in C++ code

2018-07-24T10:00:30Z

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 . 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

Bump copyright year

2016-09-10T11:54:17Z

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

fortify-headers/include/sys/select.h, branch add_old_gcc

Fix compilation under clang

Add missing include in select.h

add initial clang support

avoid __extension__ with clang

Make use of __builtin_dynamic_object_size

Don't use __extension__ in C++ code

Bump copyright year

Add __extension__ mark to include_next to silence -pedantic

Use the __inline__ keyword instead of __inline to avoid breakage

Use namespace-safe macro, param and variable names

avoid extension with clang

Don't use extension in C++ code

Add extension mark to include_next to silence -pedantic

Use the inline keyword instead of __inline to avoid breakage