Message-ID: <393959CC.186D9B30@softhome.net>
Date: Sat, 03 Jun 2000 22:17:32 +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: "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: <3939239A DOT 18870 DOT 336AAF AT localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

"Mark E." wrote:
> 
> > Sorry for too guick and hot-tempered reply.
> 
> No need to be sorry. Actually, I didn't detect an angry response, so I never
> even had a chance to be offended.

My English knowledge says that 'hot-tempered' does not include 'offensive' at all :)

> Fine by me. If they don't go for that, we'll have to change our headers. So
> let's all hope they go for it.

OK, so let's sum up the long-standing discussion:

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. But at least they're not going
to remove #include_next from limits.h, so currently there is no problem.

2) float.h - problem with it are in the past now. 

Note that limits.h and float.h are treated by GCC independently from each other
and from other header files.

3) iso646.h and stdbool.h - those C9X header file is present in GCC and missing 
in DJGPP. So currently it is OK, it's even usable, but problems can arise when 
we add 'em to DJGPP. Then they should be treated like -

4) stdarg.h stddef.h varargs.h - our major headache. Our headers have our own
file level sentinels (#ifndef __dj_include_stddef_h_), 

gcc headers have their own sentinels

#if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
     && !defined(__STDDEF_H__)) \
    || defined(__need_wchar_t) || defined(__need_size_t) \
    || defined(__need_ptrdiff_t) || defined(__need_NULL) \
    || defined(__need_wint_t)

So one of the posibilities is to add __dj_include_whatever_h_ to GCC sentinels.

Also there are sentinels guarding indvidual definitions. In DJGPP they guard
only typedefs in <sys/djtypes.h>, in gcc they guard (almost?) everything.
The fact that DJGPP guards only typedefs makes it hard to impossible fix
gcc headers this way without adjusting ours.

So right now I see adding __dj_include_foo_h_ to GCC headers as a Must Have.
Since all current GCC definitions are OK with us, we might stop there.
In other case, we could add something like

#ifdef DJGPP
#include <sys/djtypes.h>
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
#else
...
#endif

But I doubt usefulness of this thing. It helps only for typedefs.

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. If not the backward compatibility, it would be a nice and
clean solution. But I hope we won't have to use it.

Anything else?
Laurynas