From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10731 invoked by alias); 7 Jul 2013 16:21:09 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 10698 invoked by uid 55); 7 Jul 2013 16:21:06 -0000 From: "joseph at codesourcery dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/15720] stdc-predef.h wrongly defines __STDC_IEC_559_COMPLEX__ Date: Sun, 07 Jul 2013 16:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00029.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15720 --- Comment #3 from 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.