delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/07/20/12:13:10

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
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019