Date: Sun, 3 Dec 2000 09:30:23 +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: <3A2A032A.3980F482@softhome.net>
Message-ID: <Pine.SUN.3.91.1001203092432.1124N-100000@is>
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:

> > I thought that fixing fixincludes to DTRT with DJGPP should help solving
> > these problems.  Doesn't it?
> 
> Fixincludes are meant to fix ANSI incompatibilities in system headers.

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.

> > 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?

I don't trust the GCC core developers to be cautious enough not to break 
the DJGPP port, especially since the platform is not important to them.
So I think we should try to make the library as robust as possible in
the face of possible incompatible changes in GCC.

> <iso646.h>
> <stddef.h>
> <stdbool.h>
> <stdarg.h>
> <varargs.h>
> and fixincluded our <stdio.h>.

Thanks.  I think stddef.h is the only problem, then.

> I assume you don't need a list of C++ headers, do you?

No.