Message-Id: <200006041728.UAA12854@mailgw1.netvision.net.il>
Date: Sun, 04 Jun 2000 20:26:56 +0200
X-Mailer: Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
To: lauras AT softhome DOT net
CC: snowball3 AT bigfoot DOT com, djgpp-workers AT delorie DOT com
In-reply-to: <393A6E2A.AC50E842@softhome.net> (message from Laurynas Biveinis
	on Sun, 04 Jun 2000 17:56:42 +0300)
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>
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

> Date: Sun, 04 Jun 2000 17:56:42 +0300
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> If I understand correctly, the problem is that #include_next will fail if
> second header file is not found. Embedded systems may have that header file
> and may have not. 

Thanks for the info.

> > 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, Mark convinced GCC maintainers not to install float.h for DJGPP. 
> One less headache.

Yes, this is great news!

> They think they're doing The Right Thing for those zillions of platforms
> GCC runs on - they provide some headers to ensure that if you #include <stddef.h>
> then you really get NULL etc. It is hard for me to understand, see by yourself:
> 
> >  > As far as OpenBSD goes, we are willing to fix our header files over time.
> >  > The NULL issue is now solved, and everything will be alright in that
> >  > regards for 2.6.
> >That doesn't matter.  GCC still needs to work on those systems where you have
> >not updated your header files.  Or if we find another need to update a header
> >file it is not acceptable to have to wait for another OpenBSD release to fix
> >the header files.

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.

> If you want to see it yourself, do a search in gcc mail archives for
> USER_H, both in gcc AT gcc DOT gnu DOT org and gcc-patches AT gcc DOT gnu DOT org.

I will try.

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