This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC headers and DJGPP port


> Date: Tue, 18 Jul 2000 04:10:45 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> > NULL is defined as __null on all platforms now

> Not in DJGPP.  __null causes trouble in C programs.

The definition I was talking about does not.

> And yes, we did read all the threads in GCC archives that appear to
> be relevant, and we did discuss them at length.  But we still do not
> understand the technical considerations that caused GCC to insist on
> installing its own headers.  Please help us understand this.

Well, I reviewed stddef.h, as it is one of the culprits.  After
reading it, I came to the conclusion that we can probably eject it
from the compiler safely.  It does seem like there is little reason to
have it in the compiler, better to be apart of newlib, of glibc, and
then all the complexity of it, and the heartache it causes, goes
away, permanently.

We can even autoconf the target headers, and provide it, if the target
doesn't (to be backward compatible with systems that didn't have it
because of gcc), and to not provide it, if the target system has one.

The other headers, like varargs.h, might as well be in the compiler.
The compiler has to be able to generate code, assuming it does this,
it _must_ know about the varargs mechanism.  Because it already must
know about it, it doesn't require any more information to have gcc
provide stdarg.h and varargs.h, because the compiler generates them,
they are consistent with the compiler, and cannot be wrong (experts
need not correct me, I know this is a lie).

Not, all libcs can replicate varargs, but why force them to?  What
good is it?

Another example of a header we can eject is assert.h.  I don't see a
good reason for it to stay in gcc anymore.  Sure, gcc can provide
it, if the system is unwilling, but that should be rare (and rarer
as time goes on).

> Date: Tue, 18 Jul 2000 04:11:53 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.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.

#inlcuding varargs.h doesn't help gcc generate varargs code.

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

Of course not.  There is no need.

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

?  I am at a complete loss as to what to say to this.  Explain how
varargs.h could break the library.  I don't understand how it could.

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

Sure, they can.  But why should they duplicate the work and hair of
varargs.h?  There is a slight chance that the compiler vendor 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.

Your experience dealing with system vendors differs from our
experience dealing with vendors.

> To: Eli Zaretskii <eliz@is.elta.co.il>
> From: Geoff Keating <geoffk@cygnus.com>
> Date: 18 Jul 2000 09:37:01 -0700

> > I already posted a response: size_t and the rest *are* known at build
> > time: they are defined in the system headers.  GCC could simply use
> > them to build itself.

> It can't do that because your headers might conflict with the
> headers on the system that GCC is being built for.  I'm sure you're
> not trying to claim that someone can include both your <stddef.h>
> and the one on Solaris at the same time...

?  This is a non-issue.  The target compiler never includes
/usr/include, so no conflict is in fact possible.



Bottom line, If you want to do up patches to autoconf for stddef.h,
assert.h and iso646.h and not install them if the system already has
them, I'd invite you to, I don't think anyone will argue to keep them.
Before we do this, I'd like a person like drepper to buy into it as
well, though I don't think he'll mind.

varargs.h, I think we should reject, and other headers I think we'd
need to talk about specifically and weigh the issues.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]