Date: Sun, 3 Dec 2000 13:30:31 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: djgpp-workers AT delorie DOT com Subject: Re: Patch: make GCC & DJGPP headers compatible In-Reply-To: <3A2A0EF7.1232ABE9@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Sun, 3 Dec 2000, Laurynas Biveinis wrote: > A more general question - do you agree that our headers have to be > changed, either by us or by fixincludes? If you do, then my point is that > we should apply my patch. Even if fixincludes would fix the very same problem > (but maybe in a different way), with my patch we can be sure that fixincludes > won't do something unpredictable with headers, and we don't have to check that > fixincluded headers still DTRT. Sigh... My understanding was that somehow, fixincludes _eliminates_ the need for patching our headers. That's why I bothered to make fixincludes work for DJGPP. Was that a waste of time? Isn't it correct that headers fixed by fixincludes are installed in the GCC's include directory? If so, any fixing that our headers need will be done when fixincludes runs. And since fixincludes only found two marginal problems with our headers, I thought we don't need to change anything important (those marginal problems can be postponed until v2.04). That's not what I saw from your suggested changes. So I'm confused. > > > > What I'm trying to understand is whether our headers or the headers > > > > installed by GCC's "make install" procedure take precedence when you > > > > compile a program. > > > > > > GCC headers. > > > > Can we do it the other way around, somehow? > > Why should we, if GCC headers DTRT? Because I don't trust GCC to DTRT from here to eternity. See below. > > I don't trust the GCC core developers to be cautious enough not to break > > the DJGPP port > > Well, I disagree. They aren't mad enough to change _our_ size_t definitions > in djgpp.h. They can break DJGPP port in zillions of other ways, but not this > one. They can break what you done by changing the name or the semantics of the _SIZE_T macros. > > So I think we should try to make the library as robust as possible in > > the face of possible incompatible changes in GCC. > > Is my patch OK for this? I'm trying to make up my mind on that. As things are, I'm not sure. However, if I'm the only one who cares, and the others feel comfortable with this change, feel free to disregard me and commit the changes.