Date: Mon, 15 May 2000 19:45:30 +0300 (IDT)
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, "Mark E." <snowball3 AT bigfoot DOT com>
Subject: Re: more gcc issues
In-Reply-To: <392009C8.BF657179@softhome.net>
Message-ID: <Pine.SUN.3.91.1000515194235.12234L-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 Mon, 15 May 2000, Laurynas Biveinis wrote:

> It is possible that e.g. <stdarg.h> contains GCCisms which allow generating
> more efficient code, uses builtins, etc. On systems where GCC isn't primary
> compiler, this could be a problem. On DJGPP we just already have GCC-tailored
> headers, that's it.

The point I'm trying to make is that GCC cannot safely assume what does a 
random stdarg.h include.  It might as well include more than what the 
ANSI standard says, for some reason that is private to the library.  If 
the header is replaced by GCC's one, the library is broken.

In other words, if GCC wants to have its way with something that is 
usually part of stdarg.h, that doesn't automatically mean it can replace 
*all* of stdarg.h.

This is more important for float.h and limits.h, of course.