fortify-headers/include, branch masterStandalone portable header-based implementation of FORTIFY_SOURCE=3
http://git.dustri.org/fortify-headers/atom?h=master2026-04-20T21:15:31ZAvoid overflow warnings in {v,}sprintf2026-04-20T21:15:31ZSertonix2026-04-15T14:41:46Zurn:sha1:5ac7e1b695281ebdcfe365176d40053764d44684
gcc does not seem to reliably notice that the if condition makes
overflows impossible in the code. To please the compiler we can use
the __bos flag to return 0 (instead of -1) when the size is unknown.
Fixes https://github.com/jvoisin/fortify-headers/issues/62
Fixes https://github.com/jvoisin/fortify-headers/issues/68
Fixes https://github.com/jvoisin/fortify-headers/issues/80
Wrap __has_attribute and __has_builtin2026-04-12T22:04:14ZSertonix2026-04-09T09:41:59Zurn:sha1:db9e4bbab55d5c6e6ec38038f279ec14abecd4f5
Simplifies the code and improves compatibility
Make do even if PATH_MAX isn't defined2026-04-01T18:37:02Zjvoisin2026-04-01T18:37:02Zurn:sha1:60c096eb0433f7573c768a2c8523abd3c11e0720
As explained in `man realpath(3)`:
> The POSIX.1-2001 standard version of this function is broken by design,
> since it is impossible to determine a suitable size for the output
> buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX
> suffices, but PATH_MAX need not be a defined constant, and may have to be
> obtained using pathconf(3). And asking pathconf(3) does not really help,
> since, on the one hand POSIX warns that the result of pathconf(3) may be huge
> and unsuitable for mallocing memory, and on the other hand pathconf(3) may
> return -1 to signify that PATH_MAX is not bounded. The re‐ solved_path
> == NULL feature, not standardized in POSIX.1-2001, but standardized in
> POSIX.1-2008, allows this design problem to be avoided.
So we can either not compile, or be pragmatic, and define PATH_MAX to a sane
value, like 4096, which is the one used on Linux and some/most BSD.
This commit also adds two tests to ensure that things aren't catastrophically
broken by this change.
Improve portability for compilers without __has_attribute2026-03-13T00:21:30Zjvoisin2026-03-13T00:21:30Zurn:sha1:fa01a693ae41beda27dbf0948bd30bc8b57d90fcFix compilation under clang2026-03-13T00:11:32Zjvoisin2026-03-11T13:54:53Zurn:sha1:434d47d2b77b5d5e7a8d0ecc8bfa435579c9a008
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
Fixes compilation with clang and -D_FORTIFY_SOURCE=22026-03-13T00:11:26Zjvoisin2026-03-13T00:07:17Zurn:sha1:c1642e5a43de3affa75d52c3577ee1be4c874a5d
This commit fixes the typo pass_object_size__ for pass_object_size. It also
adds tests in the CI to prevent this from happening again.
Ref https://clang.llvm.org/docs/AttributeReference.html#pass-object-size-pass-dynamic-object-size
Co-Authored-By: Sertonix
Change __warning_if into __fortify_warning_if to fix potential conflicts2025-12-30T10:34:48Zjvoisin2025-12-30T10:33:08Zurn:sha1:eec2b5e06bdb01d20f1a1125074a379e0b154d80Change __access into __fortify_access to fix potential conflicts2025-12-30T10:34:48Zjvoisin2025-12-30T10:32:19Zurn:sha1:c4c5fd41124f38a5afee02b8f604ddc21d3b199aChange __format into __fortify_format to fix conflict with LLVM libcxx2025-12-30T10:25:44ZHaelwenn (lanodan) Monnier2025-12-29T20:15:44Zurn:sha1:4797899b24d35873211cf0cd1a2a373e2db3c528
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
Add __diagnose_if annotations2025-11-14T15:56:09Zjvoisin2025-11-14T15:25:52Zurn:sha1:611069d07c14bf7ace7a75fa2bc9147db8ac097d