Hi Eli,
> Building the latest version of Texinfo, I see that Gnulib decides to
> generate its own alloca.h header even though there's a system header
> alloca.h (and HAVE_ALLOCA_H is 1 in config.h). Why does it do that?
Generally speaking, we (gnulib developers) put effort into generating
zero code in the object files on platforms which implement the POSIX
standard plus the desired GNU extensions. We don't put as much effort
into using avoiding a gnulib-generated .h file because
- whether the gnulib-generated .h file exists or not, the code size
in the generated binaries is the same,
- when we have extra code that decides when to omit the .h file, we
have to update it each time we add a new workaround for one of the
types/macros/functions defined in this .h file.
In other words, it costs maintenance effort and provides little gain
(except for purists).
> Isn't that dangerous? e.g., it could conflict with how the system
> header defies 'alloca', no?
One of the problems the current code avoids is that on old AIX versions,
<alloca.h> had a #pragma which was only effective when <alloca.h> was
the first system include file to get included. This was a very annoying
restriction (must always include <alloca.h> first, after <config.h>),
and IIRC this is one of the things that the current gnulib code fixes.
Bruno
