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

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sun, 7 Nov 2004, Zack Weinberg wrote:

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

In this particular case at least the vendors can reasonably be expected to 
add the definitions to their systems so new operating system releases 
shouldn't be affected by them.  Fixing up old systems to make them work 
better isn't so problematic as fixes which keep applying to new systems 
even when not needed.  Though some vendor might come up with a header for 
which a simple bypass on FLT_EVAL_METHOD doesn't work.

We do need better tracking of which fixes are actually being used, on what 
systems.  Perhaps the instructions for sending build status reports should 
be changed to include sending some file fixincludes is made to create with 
a list of the fixes that got used and on what headers.

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

The trouble is that all those names are only reserved as macros when the 
relevant headers are included.

va_list is the most problematic case in general, given that for ISO C 
<stdio.h> must use the type (under some other name) but not define it, 
while SUS requires <stdio.h> to define it.  Fixing systems not to define 
it unconditionally in <stdio.h> is something I do think we should get out 
of, as providing <stdio.h> has not traditionally been something we do; 
it's ensuring the correct type, in the presence of <stdio.h> that might 
define it itself under some reserved name rather than deferring to the 
system's <stdarg.h>, that's the problem.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)