From: "Laurynas Biveinis" <lauras AT softhome DOT net>
Date: Tue, 10 Jul 2001 18:12:53 +0200
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: Comments on GCC 3.0 distribution
Message-ID: <20010710181253.A472@lauras.lt>
Mail-Followup-To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	djgpp-workers AT delorie DOT com
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010708110538 DOT 24414F-100000 AT is>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SUN.3.91.1010708110538.24414F-100000@is>
User-Agent: Mutt/1.3.18i
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


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

Well, I don't have GCC sources right here to check it. Does our limits.h
have non-standard symbols, so that's the problem?

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

I don't understand. If stddef.h includes sys/djtypes.h but references
only few particular types found in GCC's stddef.h, then where's the problem?

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

I've already done that, when I made patches to use GCC builtins in our
headers some time ago.

Laurynas