Message-ID: <3A2A0EF7.1232ABE9@softhome.net> Date: Sun, 03 Dec 2000 10:14:31 +0100 From: Laurynas Biveinis X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Patch: make GCC & DJGPP headers compatible References: Content-Type: text/plain; charset=iso-8859-4 Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > That was in the past, when fixincludes was first invented (and was a > shell script). Nowadays, it is mainly the way to get the system headers > be compatible with what GCC wants them to be, not necessarily due to ANSI. OK. 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. > > > 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? > 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. > 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? > Thanks. I think stddef.h is the only problem, then. Agreed. Laurynas