Date:	Tue, 18 Jul 2000 04:11:53 -0400 (EDT)
Message-Id:	<200007180811.EAA06919@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	mrs AT windriver DOT com
CC:	djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org
In-reply-to:	<200007172128.OAA29590@kankakee.wrs.com> (message from Mike Stump
	on Mon, 17 Jul 2000 14:28:17 -0700 (PDT))
Subject:	Re: GCC headers and DJGPP port
References:	<200007172128 DOT OAA29590 AT kankakee DOT wrs DOT com>
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

> From: Mike Stump <mrs AT windriver DOT com>
> Date: Mon, 17 Jul 2000 14:28:17 -0700 (PDT)
> 
> Simple, gcc knows the target system, including details that affect
> these things.  Does it mean that gcc has to know a bit about target
> system, sure.

GCC should have no problems knowing a bit about a target system: it
just needs to include the system headers for that.  It's all there.

> Understand why we #define it to __null and you'll gain a better
> understanding of the varargs.

This is *exactly* the point: no matter how much we read and re-read
the relevant discussions in GCC archives, we could _not_ understand
why there's a need for __null in C programs.  That's why Laurynas
wrote his message in the first place: we are asking to help us
understand the technical issues behind this, so we could suggest
plausible solutions.

> But.h, is another good example.  Ours works, it'll always work, we
> prefer it, why not use it?  Is your version safe with
> -fstrict-aliasing?  Are you sure?  By using ours, we know ours is.

Are you sure your version doesn't break the library?  I don't think
you can be sure of that, unless you really studied the internals of
that particular library.

IMHO, it is the business of library maintainers to make sure their
definitions work correctly.  While suggesting to use GCC's definitions
is nice, they should not be _forced_ on the library, because there's a
slight chance that the library maintainers can indeed get it right on
their own.

In other words, the possibility that system headers might not work
right is IMHO not a valid technical reason to force a library to use
different definitions.  GCC should simply assume that the system
headers work, and if they don't, tell the maintainers to get them
right.  At least with libraries that are Free Software this should
work.

- Raw text -