Message-ID: <393A6E2A.AC50E842@softhome.net>
Date: Sun, 04 Jun 2000 17:56:42 +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: "Mark E." <snowball3 AT bigfoot DOT com>,
        DJGPP Workers <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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Sat, 3 Jun 2000, Laurynas Biveinis wrote:
> 
> > 1) limits.h - it uses #include_next. Fine with us, not very fine with GCC maintainers.
> > It is somehow wrong for embedded systems, as they say. That was the reason, why
> > #include_next wasn't adopted to other header files.
> 
> I'm afraid I don't understand their reasoning.  Does someone know more
> about this?  Any pointers to discussions on public forums?

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. 

> 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. 
Their limits.h checks for redefinitions. Other way around - well, we've
got nowhere.

> 
> > 2) float.h - problem with it are in the past now.
> 
> How do you mean: in the past?  Does GCC install its own float.h?  If so,
> how can we be sure that it won't conflict with the DJGPP library?

No, Mark convinced GCC maintainers not to install float.h for DJGPP. 
One less headache.

> > So right now I see adding __dj_include_foo_h_ to GCC headers as a Must Have.
> 
> The key to this is to understand why does GCC insist on installing its
> own headers.  Using them when GCC is built is one thing, but installing
> it is quite another!
> 
> Can someone please explain why does GCC want to install its headers?

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.

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.

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?

> > In the case GCC maintainers do not accept that, one of the remaining
> > solutions (not counting overriding USER_H, omiting offending files etc.)
> > is to change our file-level sentinels from __dj_include_foo_h_ to
> > _ANSI_FOO_H.
> 
> How can we be sure these sentinels won't change?  I think we cannot.

I doubt that they will *change* sentinels instead of *adding* new ones.

Laurynas