From: Mike Stump Date: Tue, 18 Jul 2000 20:46:05 -0700 (PDT) Message-Id: <200007190346.UAA01039@kankakee.wrs.com> To: eliz AT is DOT elta DOT co DOT il, martin AT loewis DOT home DOT cs DOT tu-berlin DOT de Subject: Re: GCC headers and DJGPP port Cc: djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org Reply-To: djgpp-workers AT delorie DOT com > Date: Tue, 18 Jul 2000 04:10:45 -0400 (EDT) > From: Eli Zaretskii > To: martin AT loewis DOT home DOT cs DOT tu-berlin DOT 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 > To: mrs AT windriver DOT com > > From: Mike Stump > > 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 > From: Geoff Keating > 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 > 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.