bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnulib's alloca.h used even when there is a system header


From: Bruno Haible
Subject: Re: Gnulib's alloca.h used even when there is a system header
Date: Mon, 18 Feb 2019 00:28:06 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]