Date:	Mon, 15 May 2000 18:16:09 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: more gcc issues
In-Reply-To:	<391FC6AB.3330.951E1@localhost>
Message-ID:	<Pine.SUN.3.91.1000515181222.12234B-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 Mon, 15 May 2000, Mark E. wrote:

> > My greatest fears are with limits.h and float.h.  We have there some
> > library-private defines, like NAME_MAX, __dj_double_epsilon, the
> > _control87 bits, etc.  We cannot possibly hope that the version which
> > comes with GCC will DTRT, unless they have some trick to include the
> > system header from theirs (do they?).  So, unless they withdraw these
> > two headers, we will have to change ours if they are incompatible.
> 
> GCC's limits.h does call the system's limits.h so this isn't a problem.  

How does it pull that trick?

> float.h on the other hand does not currently do this.

Is there any reason not to ask GCC maintainers to do that in float.h as 
well?

Also, including the system header might not solve all the problems, 
unless when the system header is included, the GCC's definitions are 
bypassed.  If not, what GCC defines might be in conflict with what we 
do.  (Unfortunately, I don't have the sources handy to look there and
say something more intelligent, sorry.)

- Raw text -