From: "Mark E." <snowball3 AT bigfoot DOT com>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Thu, 20 Jul 2000 12:13:02 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: GCC headers
Message-ID: <3976ECCE.11486.EB6CD@localhost>
References: <3976E019 DOT 32763 DOT 16018F AT localhost>
In-reply-to: <Pine.SUN.3.91.1000720183326.28054A-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

> I'm sorry for asking more questions, but I don't want to make a fool out 
> of ourselves when I reply to Martin Loewis.
> 
> > #ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
> > #define _GCC_LIMITS_H_
> [...]
> > #else /* not _GCC_LIMITS_H_ */
> > 
> > #ifdef _GCC_NEXT_LIMITS_H
> >  #include_next <limits.h>		/* recurse down to the real one */
> > #endif
> 
> This seems to be a provision for using our limits.h instead of the one 
> GCC supplies.  But I don't understand how are _GCC_LIMITS_H_ and 
> _GCC_NEXT_LIMITS_H supposed to be defined.  Do they come from specs?

_GCC_LIMITS_H is the include guard. _GCC_NEXT_LIMITS_H is defined and then 
undefined in the generated "sysinclude.h" and ends up in gcc's include 
directory:

/* syslimits.h stands for the system's own limits.h file.
   If we can use it ok unmodified, then we install this text.
   If fixincludes fixes it, then the fixed version is installed
   instead of this text.  */

#define _GCC_NEXT_LIMITS_H		/* tell gcc's limits.h to recurse */
 #include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H

> 
> Also, is this include_next gork present in the other headers GCC wants
> to install?

Not that I'm aware of.

Mark