X-Mailer:	exmh version 2.0.2
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	mrs AT windriver DOT com, djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org,
	martin AT loewis DOT home DOT cs DOT tu-berlin DOT de
Subject:	Re: GCC headers and DJGPP port
In-reply-to:	Your message of Sat, 22 Jul 2000 05:19:10 EDT.
	<200007220919 DOT FAA12001 AT indy DOT delorie DOT com>
Mime-Version:	1.0
Date:	Sat, 22 Jul 2000 10:32:55 -0600
Message-ID:	<10276.964283575@upchuck>
From:	Jeffrey A Law <law AT cygnus DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

  In message <200007220919 DOT FAA12001 AT indy DOT delorie DOT com>you write:
  > My information indicates that the relevant headers are: assert.h,
  > stddef.h, iso646.h, limits.h, stdbool.h, and syslimits.h.
I would be willing to consider not installing if and only if we
know the system versions are correct.  Just saying yours are correct isn't
sufficient, you actually have to test them.  I think you'll find that it's
far easier to just let GCC install the headers it expects and deal with it.

Other systems which have their own stddef.h, limits.h, etc etc manage to
work just fine when using GCC's versions.  Why can't yours?

[ Yes, the exception is certain *BSD* systems which mistakenly have overridden
  USER_H for about 7 years and as a result never have made GNU's stddef.h work
  properly with their system. ]

Let's take the __null issue again.  According to the C++ standard it is
an implementation-defined C++ null pointer constant -- it also states
that (void *)0 is not an acceptable value.

It turns out that using "0" doesn't work, nor does "0L" for reasons I
can't remember.

The C++ experts on this list decided the best solution which would
satisfy the C++ standard in a generic way was to define NULL as a builtin
implementation defined C++ constant via __null and have the compiler make
sure it had the right type/value internally.

By not using GNU's stddef.h you're going to get a non-compliant stddef.h.


Now, let's assume that you fix your stddef.h and claim that you're compliant
now.  You may be right as far as NULL is concerned, however we may come across
other compliance issues in the future which might require additional tweaks
to stddef.h, stdbool.h, etc.  We fix them, but because you're not installing
the fixed header files your implementation still has whatever non-compliance
issues we found and fixed for GCC's internal header files.

This isn't unlike the systems that didn't run fixincludes because their headers
where "compliant" or didn't install GCC's fixed headers for the same reason.
Well, it turns out most were not compliant because of a bogus
'struct exception' in math.h which GCC knew how to fix and could have made
the header files on those systems compliant.

I'm of the opinion that compliance in header files is never actually achieved,
you just get closer and closer over the years. 

jeff

- Raw text -