Message-ID:	<393A8738.B5DA430D@softhome.net>
Date:	Sun, 04 Jun 2000 19:43:36 +0300
From:	Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer:	Mozilla 4.72 [en] (Win98; U)
X-Accept-Language:	en
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	snowball3 AT bigfoot DOT com, djgpp-workers AT delorie DOT com
Subject:	Re: Testers wanted: a fix for GCC header problem
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000604175351 DOT 11052H-100000 AT is> <393A6E2A DOT AC50E842 AT softhome DOT net> <200006041728 DOT UAA12854 AT mailgw1 DOT netvision DOT net DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> > > Also, #include_next redefines the constants that are already defined (by
> > > whatever precedes it in the header GCC installs), no?  If so, the
> > > compiler could print warning messages under some restrictive -Wfoo option.
> >
> > Oops. Missed that. If our header comes first, this is not a problem.
> 
> Our header can only come first if theirs does #include_next right at
> the beginning.  Does it?

No.

> I've read this when Mark posted a pointer to this thread, but I don't
> see any rationale here, only a postulation of a principle with no good
> justification.

Neither I did.

> > Also, this is in some way related with fixincludes. Could anyone on
> > unix/linux/whatever run fixincludes on DJGPP headers and post what
> > changes are made?
> 
> IIRC, fixincludes is only required where system headers contradict
> ANSI.  At least that was its original intent.

That's why I want to check them. We could be surprised. At least I saw 
one fix there related with va_list in stdio.h issue there.

Laurynas

- Raw text -