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

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

- Raw text -