Date: Tue, 18 Jul 2000 04:11:53 -0400 (EDT) Message-Id: <200007180811.EAA06919@indy.delorie.com> From: Eli Zaretskii 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 Precedence: bulk > 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. > 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.