[bug-gnulib] Re: automatic prototypes

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> I guess the controversial aspect is putting too much things into
>> config.h...
>
> Yes. It's handy, but it seriously limits the ability to work around problems
> on exotic platforms.
>
> In the case of strdup you are lucky because its prototype uses only
> built-in types. Even for strlen(), which uses size_t, you would need to
> add #include <stddef.h> to config.h.

Right.  I'm trying to understand exactly what bad things will happen
in practice as a result of doing so.

> As you may know, we put the #define _GNU_SOURCE also in config.h, and
> it has no effect if another system header has already been included before.
> So the config.h will not work if your strlen declaration comes textually
> before the _GNU_SOURCE define.

Right, ordering is critical, but it doesn't seem impossible to solve
(see below).

>> OTOH, alloca.h has always seemed a bit fragile to me, and it might
>> actually be better to move that definition to config.h.
>
> Our alloca.h replacement also include <stddef.h>. Same problem.

It is only the same "problem" if you consider #include's in config.h
to be a problem, and I'm not sure I have understood why that is the
case yet.

I know it is not standard procedure, and I have tried #include's in
config.h before, with some bad results, but all problems I
experienced, and can think of, seem solvable, but it may require some
work.

> The only room for improvement that I see would be if autoconf would provide
> an AH_BOTTOM macro with priorities, say
>
>    AH_BOTTOM(200,[#include <stddef.h>])
>    AH_BOTTOM(10,[#define _GNU_SOURCE])
>    AH_BOTTOM(99,[#include <alloca.h>])
>
> which would generate a config.h that looks like this:
>
>    /* Priority 10 */
>    #define _GNU_SOURCE
>    /* Priority 99 */
>    #include <alloca.h>
>    /* Priority 200 */
>    #include <stddef.h>
>
> This would allow us to define standard priorities for simple #defines,
> early include files, normal include files etc.

I'm not sure this is necessary.  It seems all #define's for standard
autoconf tests should go first, but if AH_BOTTOM is used, they would
already do that.  And gnulib-tool could be used to guarantee that the
ordering of AH_BOTTOM calls is in the correct order, because it knows
the dependency tree of the modules.  It seems safe to assume that if a
gnulib module A depend on another module B, the AH_BOTTOM from module
B should come before the one for A.  There is a potential problem with
circular dependencies, but I don't think it is a problem for the *.h
snippet (otherwise, which of the header files for A or B should an
application include first?).

Thanks,
Simon