From:	Zack Weinberg <zack AT wolery DOT cumb DOT org>
Date:	Sat, 22 Jul 2000 16:02:26 -0700
To:	Mike Stump <mrs AT windriver DOT com>
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
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

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 <limits.h> 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
<syslimits.h> 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 <limits.h> 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 <wchar.h>.  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

- Raw text -