Re: GCC headers and DJGPP port

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Thu, Jul 20, 2000 at 12:29:45PM -0700, Bruce Korb wrote:
> Zack Weinberg wrote:
> 
> > The vast majority of the complexity of stddef.h has to do with how it
> > interacts with system-provided headers.  Not on the actual definition
> > of size_t, etc. but on the interlock mechanism which prevents
> > duplicate typedefs.  And I don't think fixincludes is prepared to help
> > with that.  It would need a huge table recording the appropriate
> > interlock to use for each platform.
> 
> No.  Actually, fixincludes has always "fixed" the headers
> that typedef these by wrapping them as I described.  What would
> happen if someone #include-d stddef.h before another system
> header that typedefed the same thing?  Nothing bad only because
> fixincludes was there first and wrapped the duplicate typedef.
> Since this has already been done, and since you can rely on it,
> it seems that the complexity is unnecessary, yes?

Are you certain that fixincludes does this thing for every platform
that might have problems, to every header that might have problems?

I'd believe we can chuck out a lot of it, not all.  For instance, the
BSDs don't run fixincludes, and they have their own stddef.h which
ours must match (when we are installed in /usr/local instead of from
the BSD unified tree).  And then there's the platforms using
fixinc.wrap or fixinc.svr4...

> > I might also add that some modern C libraries, such as glibc, know
> > exactly which headers are provided by gcc and do not have their own
> > copies.

glibc expects gcc to provide stddef.h, and includes it dozens of times
with special __need_something macros defined.  It expects gcc to
provide limits.h, and engages in mutual #include recursion between its
own limits.h and ours.

As I understand it, those are two of the three headers we're
discussing dropping where possible - the other being assert.h.  And I
am all for this idea, but we need to pay close attention to how it's
done.

zw