From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Thu Oct 1 23:37:26 2015 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 1627A35868C; Thu, 1 Oct 2015 23:37:26 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by www.open-std.org (Postfix) with ESMTP id 9F3DA356DEA for ; Thu, 1 Oct 2015 23:37:21 +0200 (CEST) Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZhlXS-00004F-Hf from joseph_myers@mentor.com for sc22wg14@open-std.org; Thu, 01 Oct 2015 14:37:18 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Thu, 1 Oct 2015 22:37:17 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1ZhlXP-0006M4-R1 for sc22wg14@open-std.org; Thu, 01 Oct 2015 21:37:15 +0000 Date: Thu, 1 Oct 2015 21:37:15 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Subject: TS 18661 tgmath.h and feature test macros Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-sc22wg14@open-std.org Precedence: bulk The feature test macros in the various parts of TS 18661 are specified in terms of whether the macro is defined when a header is first included. Consider a program that does: #include #define __STDC_WANT_IEC_60559_TYPES_EXT__ #include #include Then did not declare csinf64, but did declare sinf64. Does this mean that a program can then call the type-generic sin macro with an argument of type _Float64, but not with an argument of type _Complex _Float64, so needs to deal with various permutations of what functions are declared by what headers, taking into account the macros defined when those headers were included and not just when was included, in order to handle the correct set of types for each function without using undeclared functions (when decimal floating point is included you get yet more combinations)? (And so the example cbrt macro given in TS 18661-3 would be overly simplistic, in that a program could have included , then defined __STDC_WANT_IEC_60559_TYPES_EXT__, and only then included , in which case the latter cbrt macro not allowing for _FloatN / _FloatNx would be the right one.) In the above case, would it however be valid to call sin with an argument of type _Imaginary _Float64, because that would map to sinhf64 rather than to a complex function? Do I understand correctly that if __STDC_WANT_IEC_60559_TYPES_EXT__ but not __STDC_WANT_IEC_60559_BFP_EXT__ is defined, then for the new functions added in part 1 that have _FloatN etc. versions added in part 3, the versions for float etc. are not declared in ; the macros are not defined in ; but the versions for _Float64 etc. *are* declared in ? Or is the intent that the versions for _Float64 etc. (e.g. roundevenf64) require both feature test macros to be declared at all? Requiring both feature test macros would make more sense and accord with what we ended up with in part 4 for similar issues, but it's difficult to tell from the TS text whether the declarations end up being conditioned on two feature test macros like that. (Incidentally, while investigating this issue I noticed a typo in part 3, at least as of the N1945 draft: page 32 has "_DecimalNx scoshdNx(_DecimalNx x);", where scoshdNx should of course be coshdNx.) -- Joseph S. Myers joseph@codesourcery.com