From: Zack Weinberg Date: Sat, 22 Jul 2000 16:02:26 -0700 To: Mike Stump Cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org, martin AT loewis DOT home DOT cs DOT tu-berlin DOT de Subject: Re: GCC headers and DJGPP port Message-ID: <20000722160226.A263@wolery.cumb.org> References: <200007222219 DOT PAA01604 AT kankakee DOT wrs DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007222219.PAA01604@kankakee.wrs.com>; from mrs@windriver.com on Sat, Jul 22, 2000 at 03:19:20PM -0700 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, Jul 22, 2000 at 03:19:20PM -0700, Mike Stump wrote: > > If it's okay with you, I'd like to discuss limits.h (and syslimits.h > > that is related to it) first. Why is it necessary for GCC to install > > its own version of this header? > > Wrong question. I'll answer it anyway, because it is best. It is > best, because gcc already knows so much about the target system, that > it can generate this file. I'd like to chime in here, because I believe there is a clear case for dropping from GCC's provided headers, much clearer than any other header we provide. Unlike all the other headers we provide, its contents are not solely dictated by the C standard. In a freestanding environment, sure, you can get away with only defining the various TYPE_MAX and _MIN macros. In an unusual hosted environment that provides nothing but the features of ISO C, again, we're fine. But the moment you bring in POSIX, or XPG, or historical BSD or SysV, or *anything* that extends the C standard, dozens of values are added to limits.h. gcc doesn't have enough information to probe for all those values. It doesn't even know what they are. So instead we use #include_next and to get both our limits.h and the system's limits.h included. I don't understand the way that mechanism does work, in fact I would bet that no one does. I know it doesn't work as it was intended to; it tries ever so hard not to defeat the multiple include optimization - and fails. It's so fragile that it breaks if you disable the MI optimization - which should be impossible! And it gains us *nothing*. The system will have all the definitions we're trying to provide. It has to. All the standards limits.h might conform to are strict supersets of C89. C99 adds values to limits.h, but we don't need to provide them any more than we need to provide C99 . An archaic system like Michael S.'s 4.3BSD might not have it at all - okay, so we can provide a fallback, or have fixincludes patch in any missing definitions. But we don't need to force our header on the majority of systems in common use, that have perfectly good limits.h already. A similar argument can be made for assert.h, stddef.h, and possibly float.h, but these headers do not cause nearly as much trouble as limits.h. Limits.h must die. zw