Re: Getting glibfortran to build on newlib targets aka. missing stdint.h (PR 14325)

[Zack Weinberg <zack at codesourcery dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Sun, 7 Nov 2004, Zack Weinberg wrote:
>
>> In particular I do not think we should fix a non-C99 conformant
>> system-provided float.h, and I am dubious about continuing to
>
> If we don't fix it, then we regress in that regard.  Now, I follow a very 
> wide definition of what counts as a regression, but the fix is at least a 
> simple one of adding
>
> #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> #undef FLT_EVAL_METHOD
> #define FLT_EVAL_METHOD __FLT_EVAL_METHOD__
> #endif
>
> to a system float.h that doesn't define FLT_EVAL_METHOD, and likewise for 
> DECIMAL_DIG.

I construe this as papering over a bug in the C library in question,
and therefore not a regression if we stop doing it.  That's not a
reason _to_ stop doing it, though.

As we've been discussing off-list, all else being equal it is
desirable to edit as few library-provided headers as possible, because
fixincludes edits are inherently fragile, and because it interferes with 
changes to that C library after GCC is installed (e.g. the well-known 
inability to use a gcc  installation built against Solaris 2.x after a
system upgrade to 2.(x+1)).  This I do think is a reason not to mess
with a library-provided float.h.

> The problem with <stddef.h> is really the definition of offsetof, though 
> the C++ definition of NULL to __null comes into things as well, since by 
> design our types should always agree with those of the system header.

Here's a half-baked idea for dealing with this.  Suppose we add to
cpplib a notion of built-in invisible macros.  These have the
following semantics:

1) Before an explicit #define of the macro in question, the macro is
   not expanded.

2) An explicit #define is compared against the invisible definition,
   in a manner similar to what we do now with an explicit declaration
   of a built-in function.  However, the invisible definition
   overrides the explicit one if they don't match - with a warning,
   which is suppressed in system headers as usual.

3) In order not to drive people nuts trying to debug, -save-temps/-E
   prints out the invisible definition as a #define, with a comment
   reading "definition overridden by intrinsic", at the point where
   -dD would have printed a #define line for the explicit definition
   if it hadn't been overridden.  (These will be silently ignored by
   -fpreprocessed mode reread.)

We would need to be very careful with these; it'd be wrong to use them
for anything where the name-as-macro was not reserved by the C
standard, and it'd be wrong to use them except in cases where a
GCC-specific definition absolutely must be used.  However, I think it
would correctly handle offsetof, NULL, and possibly va_*.

I'm not all that excited about this idea - perhaps it is best to
continue forcing everyone to use our stddef.h and stdarg.h.

zw