Re: Add feature test macro _ISOC2X_SOURCE

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 9 Aug 2019, Florian Weimer wrote:

> * Joseph Myers:
> 
> > This patch does not itself enable anything new in the headers for C2X;
> > that is to be done in followup patches.  (For example, most of the TS
> > 18661-1 functions should be declared for C2X without any
> > __STDC_WANT_IEC_60559_BFP_EXT__ being needed, but the ones that
> > 18661-1 adds to Annex F because of their close relation to IEEE 754
> > formats do still need the WANT macro in C2X.)
> 
> What happened to the plan to rename the TS 18661-1 functions?  Has a
> formal decision been made?

There isn't a plan; there's someone who wants to rename either some or all 
functions, while the CFP group is against ("3) Renaming functions: 
Against, since already implemented as is, names fit with pre-part 1 C, 
consistent with existing C standard, names fit function" - see pages 28-29 
of <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2376.pdf>), and no 
specific decision ("This risk has not yet been evaluated. Several ideas 
have been discussed to resolve these issue, but none has yet resulted in a 
proposal that would find consensus." in the editors' report).

I don't think that's actually relevant to the feature test macro anyway; 
it's explicitly stated that the API enabled by the feature test macro 
might be unstable before C2X is released.  (While the ABI would be subject 
to the usual compatibility rules in the event of API changes that could 
break ABI compatibility; for example, we should keep compat symbols when 
changing totalorder to have pointer arguments; because that's considered a 
defect fix to 18661-1, there would in any case be no need to keep the old 
totalorder version available as an API as opposed to as an ABI.)

Even without renaming it's plausible some 18661-1 functions will not end 
up in C2X; specifically, the changes to minimum / maximum operations in 
IEEE 754-2019 could result in fmaxmag / fminmag being removed (see 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2273.pdf>).  I expect to 
have different __GLIBC_USE names for different subsets of 18661-1 (the 
subset in C2X unconditionally; the subset that's only in C2X when 
__STDC_WANT_IEC_60559_BFP_EXT__ is defined; any subset that's not in C2X 
at all so should not be declared for __STDC_WANT_IEC_60559_BFP_EXT__ in 
strict C2X conformance mode, unless we end up completely obsoleting such 
names as APIs).  Depending on the precise form 18661-3 integration takes 
there may also be a question about the exact feature test macros for 
18661-3 functions corresponding to the functions that, in C2X, need 
__STDC_WANT_IEC_60559_BFP_EXT__ for float / double / long double (a subset 
of the ones currently using "__GLIBC_USE (IEC_60559_BFP_EXT) || 
__MATH_DECLARING_FLOATN").

-- 
Joseph S. Myers
joseph@codesourcery.com