Date:	Sun, 3 Dec 2000 13:30:31 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: make GCC & DJGPP headers compatible
In-Reply-To:	<3A2A0EF7.1232ABE9@softhome.net>
Message-ID:	<Pine.SUN.3.91.1001203131752.2851B-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -