From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Thu Jun 6 21:50:54 2013 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id CD4F8356F51; Thu, 6 Jun 2013 21:50:54 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by www.open-std.org (Postfix) with ESMTP id 850E03569A2 for ; Thu, 6 Jun 2013 21:50:37 +0200 (CEST) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id C898522643 for ; Thu, 6 Jun 2013 20:50:36 +0100 (BST) Received: from digraph.polyomino.org.uk (HELO digraph.polyomino.org.uk) (81.187.227.50) (smtp-auth username postmaster%pop3.polyomino.org.uk, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Thu, 06 Jun 2013 20:50:36 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UkgCh-0008SW-QD for sc22wg14@open-std.org; Thu, 06 Jun 2013 19:50:35 +0000 Date: Thu, 6 Jun 2013 19:50:35 +0000 (UTC) From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: SC22 WG14 Subject: Feature test macros In-Reply-To: <20130606171247.B7A0F3569A2@www.open-std.org> Message-ID: References: <20130604143857.9B6F6356927@www.open-std.org> <20130606171247.B7A0F3569A2@www.open-std.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Gradwell-MongoId: 51b0e80c.13b07-4b42-1 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.polyomino.org.uk Sender: owner-sc22wg14@open-std.org Precedence: bulk On Thu, 6 Jun 2013, James W Thomas wrote: > > (As previously noted on 25 Sep 2012:) > > > > __STDC_WANT_IEC_18661_EXT1__ should be handled consistently with other > > __STDC_WANT_* macros. That is, following the wording from C11 K.3.1.1 > > paragraphs 1-4 (but with the new declarations not being present if the > > macro is not defined). The requirement for being identically defined > > for all header inclusions should probably be for all headers that are > > modified by this TS part ( > > ). > > > > All subsequent places in the document that show a #define of this > > macro then need to change to #define it to 1 instead of to empty. > > This issue was presented at the Oct 2012 WG 14 meeting in Portland, > where the response (without objection) was "keep it simple". Extracting this one point as something generic affecting various other documents: The Annex K practice (__STDC_WANT_LIB_EXT1__) is also followed by TR 24731-2 (__STDC_WANT_LIB_EXT2__) and ISO 24747 (__STDC_WANT_MATH_SPEC_FUNCS__). __STDC_WANT_DEC_FP__ in TR 24732 follows the looser practice given for __STDC_WANT_IEC_18661_EXT1__. The more complicated practice in Annex K is problematic in its own way. In particularly, "shall be defined identically for all inclusions of any headers from subclause K.3" appears to require a diagnostic if the definition changes between multiple inclusions of the same header, contrary to normal multiple-include optimization where a second include of the same header could generally be ignored - and "identically" would suggest identical token sequences (meaning a diagnostic if the expansion is 1 for one include and 1L for another include). A looser practice where what matters is the definition at the point of first include, and no diagnostics are required, is certainly simpler to implement. But in any case, I don't think inconsistency is helpful (and this also includes inconsistency about whether the macros are 0/1 valued, or undefined / defined). If the simpler approach is preferred, Annex K, TR 24731-2 and ISO 24747 should change to match it as far as possible without breaking compatibility. -- Joseph S. Myers joseph@codesourcery.com