Date:	Sun, 8 Jul 2001 11:06:00 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	lauras AT softhome DOT net
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Comments on GCC 3.0 distribution
In-Reply-To:	<20010707175034.2473.qmail@softhome.net>
Message-ID:	<Pine.SUN.3.91.1010708110538.24414F-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 Sat, 7 Jul 2001 lauras AT softhome DOT net wrote:

> > Thanks.  But I'm still worried a bit: what about all those additional
> > definitions we have in our headers which are private to DJGPP, or at
> > least absent from the GCC headers?  How will they be pulled in by GCC
> > if it doesn't always do a include_next, and even when the header does
> > include_next, I'm not convinced that really works in our case?
> 
> <limits.h> from GCC does include_next, and at least it worked a year ago.

Yes, it does include_next, but only if some preprocessing symbol
(whose name I forget and don't have the distro handy to look up) is
defined.  I only looked at limits.h for a few moments, but it seemed
to me that this symbol will not be defined in our case, except if
limits.h was already included at least once in the same source file.
Perhaps I missed something.

> As far as <stdarg.h> and <stddef.h> are concerned, we don't have any
> non-standard definitions there, do we?

Our stddef.h includes sys/djtypes.h, which could mean it defines more
types than stddef.h which comes with GCC (but I didn't actually
compare them type by type, partially because the GCC version of that
header is a terrible hodgepodge of ifdef's).

As for stdarg.h, it's probably okay if we know for sure their
definitions of va_* macros don't contradict ours; perhaps we should
have a short program to actually test them with all the supported data
types.

- Raw text -