summaryrefslogtreecommitdiff
path: root/include/stdlib.h (follow)
AgeCommit message (Collapse)Author
2026-04-01Make do even if PATH_MAX isn't definedjvoisin
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.
2025-12-30Change __warning_if into __fortify_warning_if to fix potential conflicts3.0.1jvoisin
2025-11-14Add __diagnose_if annotations3.0jvoisin
2025-10-31add initial clang supportDaniel Kolesa
Co-Authored-By: jvoisin <julien.voisin@dustri.org>
2025-10-31avoid __extension__ with clangDaniel Kolesa
It seems useless and triggers 'error: expected external declaration'
2025-10-31Make use of __builtin_dynamic_object_sizejvoisin
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.
2019-03-07realpath: guard slow/trap path with PATH_MAXinfo@mobile-stream.com
This allows the compiler to optimize out the slow/trap path at all for the typical correct code: char buf[PATH_MAX]; r = realpath(path, buf); The change keeps the "unknown object size" case handling intact.
2018-07-24Don't use __extension__ in C++ codeA. Wilcox
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
2016-09-10Bump copyright yearsin
2016-07-14Only include limits.h when actually usedNatanael Copa
The __extension__ seems to trigger a bug in gcc when there are no identifier specified afterwards. Testcase: echo "#include <stdlib.h>" > try.c && cc -O0 -c try.c try.c:2:0: error: expected identifier or '(' at end of input With -O2 it does not happen. We work around this by only pulling in limits.h when we actually need the PATH_MAX. Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
2015-07-16Only crash on overflow for realpath()sin
2015-06-25Add __extension__ mark to include_next to silence -pedanticSteven Barth
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-03Use namespace-safe macro, param and variable namesTrutz Behn
2015-05-13Add LICENSE headersin
2015-05-13Add fortify_fn() helper in fortify-headers.hsin
2015-05-07Minor style fixsin
2015-05-07fix realpath when stdlib.h is included before limits.hNatanael Copa
If program includes stdlib.h before limits.h without _XOPEN_SOURCE, _GNU_SOURCE or _BSD_SOURCE explicitly set, then will it always trigger the trap with musl libc. This is becase stdlib.h will pull in features.h which will set _GNU_SOURCE. This means that the fortify stdlib.h will not include limits.h but it will still trigger the fortified realpath(), but without PATH_MAX set. We fix this by including system stdlib.h before testing if limits.h should be included. Since PATH_MAX is known at compile time we can also error at compile time, instead of compiling a broken realpath().
2015-03-14Use __typeof__ to in part avoid replicating function typesTrutz Behn
2015-03-14Add __artificial__ to aid in debuggingsin
2015-03-13Restore C++ supportsin
2015-03-13Rework fortify implementation to use extern inlinesin
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.
2015-03-11Put include guards in the reserved namespaceTrutz Behn
fortify-headers is considered part of the implementation.
2015-03-11Ignore C++ for nowsin
It is not legal to override standard functions using macros in C++. We may have to revisit this in the future.
2015-03-11Add ifdef guards for C++ codesin
2015-02-28Style fixsin
2015-02-28__fortify_realpath() should trap if PATH_MAX is not definedsin
This is currently done only if the pointer is non-NULL.
2015-02-24Add realpath() checksin