[Bug libc/15720] stdc-predef.h wrongly defines __STDC_IEC_559_COMPLEX__

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15720

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 6 Jul 2013, bugdal at aerifal dot cx wrote:

> > I think this is no different from defining __STDC__ in GCC's default mode,
> > or defining __STDC_VERSION__ to indicate the selected standards mode
> > rather than to indicate full conformance to a particular standard version.
> > That is, it indicates intent rather than completeness (for example,
> > special cases of functions try to follow Annex G).
> 
> I disagree with this assessment. There's a big difference between
> minor conformance errors (like excess ulps of error) and omitting
> required types that make a valid Annex G program into a compile-time
> constraint violation. If applications can't rely on the absence of
> this macro to tell them _Imaginary is definitely not available, what
> good is the macro?

Not much good.  You can't use __STDC_VERSION__ in practice to tell what 
level of C11 features is supported, can't use __STDC__ to tell if 
trigraphs are supported, and to the extent that you can use 
__STDC_VERSION__ as an indication of availability of various C99 features 
(albeit language features only, not library features even when defined 
together with __STDC_HOSTED__), it took many years after compilers started 
having C99 modes for there to be a reasonable consensus on a common 
subsets of C99 features you could expect to be supported in such a mode 
(which doesn't include anything from Annex F or Annex G, or UCNs in 
identifiers, for example).

Such macros are only reliable for the standard-given semantics if the 
application knows it is being built by an implementation with some 
externally-given conformance statement covering the implementation as a 
whole (compiler and library) (at which point they may be used to identify 
which conformance options are in use).  For normal compilations with 
implementations documented not to implement everything in the standard, 
the macros may be of heuristic value but may also need using together with 
external information about particular implementations, or information 
obtained from autoconf configure tests.

> > responsible for the architecture ABI definition.  (Saying that imaginary 
> > types are passed like the corresponding real types is a tempting default - 
> > except that float _Imaginary does *not* promote to double _Imaginary when 
> > passed in variable arguments, so an unpromoted float _Imaginary could be 
> > passed there where an unpromoted float never could.)
> 
> I wasn't aware of this issue, but I don't think it matters. There's no
> reason from an ABI standpoint why you can't promote it, as long as
> va_arg, when passed _Imaginary float as the type, knows to perform the
> actual read as _Imaginary double instead.

Of course the ABI could be defined to promote it, though I think it would 
make more sense not to promote it - but the fact there is a reasonable 
choice about the ABI in this area is sufficient reason why the "you" 
deciding what choice to make needs to be the ABI maintainers (or in the 
absence of such ABI maintainers, any de facto group that coordinates ABI 
issues between implementations (the ia32-abi Google Group in the case of 
32-bit x86 ELF, for example)) rather than one implementor.

Just look at the 32-bit Power Architecture ABI (unified version - "Power 
Architecture(R) 32-bit Application Binary Interface Supplement 1.0 - Linux 
& Embedded") for the complexities of how complex types are handled 
(complete with two different ABI options for them in the EABI case, 
matching different implementations) for what you get if you let the ABI 
just be what happens by chance on a particular architecture for a 
particular implementation without anything actually thinking about or 
coordinating things on a per-architecture basis.

-- 
You are receiving this mail because:
You are on the CC list for the bug.