Message-ID:	<3A2A0EF7.1232ABE9@softhome.net>
Date:	Sun, 03 Dec 2000 10:14:31 +0100
From:	Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer:	Mozilla 4.76 [en] (Win98; U)
X-Accept-Language:	lt,en
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: make GCC & DJGPP headers compatible
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1001203092432 DOT 1124N-100000 AT is>
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

- Raw text -