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