Re: [bug-gnulib] Re: automatic prototypes

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> Paul Eggert <address@hidden> writes:
>
>> Simon Josefsson <address@hidden> writes:
>>
>>> Is there a problem in including standard include files in config.h?
>>
>> Emacs does that, and it has problems in practice, because the order of
>> include files is always wrong somewhere.
>
> How is it different from having the same #include statements in each
> *.c file?

The basic problem, as I recall, was namespace pollution.  Once you
include all the .h files, all the symbols get exported everywhere, and
this causes collisions in practice.  This ranges from little things
like incompatible versions of MAX, to bigger things like incompatible
versions of "open".  The NOT_C_CODE hacks of Emacs are one symptom of
this.  The seemingly-gratuituous #undefs scattered around the code are
another.

>> If memory serves, the Emacs hackers were slowly trying to change to
>> the usual way of doing things.  Don't recall if they finished.
>
> It doesn't look like they did...  There is even an #include for a
> non-system file.

They have removed some of the worst abuses, e.g., redefining "read".
(I remember that one, since I was responsible for fixing it.)  But
there is still a lot of cruft there.  It would be a massive job to
clean it up.  Don't let your code end up looking like that, boys and
girls!