Re: double-include include_next fix for Solaris 8, Sun Studio 11

[Bruno Haible]

Paul Eggert wrote:
> The problem is that Solaris 8 <time.h> eventually includes itself
> recursively. ...
> 
> I installed the following patch, which fixes the problem for Solaris 8.

Yes, it looks like a viable solution when a system header includes itself.
The other solution would have been to add more #ifdef __need_xyz, depending
on the special #include conventions that this header file has in Solaris.

> I don't have easy access to mingw

There is nothing special about mingw, regarding the replacement headers.
The #if processing is the same on all platforms, as soon as the replacement
header is in use. (Except for a few weird include conventions in glibc:
these __need_xyz as well.)

> perhaps we should use a similar solution for the other .h
> files, as it is a bit simpler.

I wouldn't say that it's simpler: The technique from lib/time.h delegates
the double-inclusion decision to the next header. Like if the header was
saying "The first time, I add my declarations, then afterwards, I delegate."
The technique from lib/stdlib.h and the others is to make a double-inclusion
decision. Like saying "The first time, I add my declarations, then afterwards
I know there is nothing new."

The practical difference is that when you have -Ilib -Ilib -Ilib -Ilib in
the CPPFLAGS, lib/time.h will delegate to lib/time.h, which will delegate
to lib/time.h, which will delegate to lib/time.h, which will delegate to
lib/time.h, which will delegate to the system's <time.h>. So that for each
redundant #include, the preprocessor opens 5 files instead of 1.

Both approaches are equally simple in terms of #ifdefs. The new approach is
more complicated regarding what happens at preprocessor time, but is
robust against recursive #includes.

Bruno