[Cfp-interest 3080] Re: [SC22WG14.24752] __STDC_WANT_IEC_60559_EXT__ and DFP interfaces

Jim Thomas jaswthomas at sbcglobal.net
Sat Apr 6 21:00:48 PDT 2024


The issue described below by Joseph Myers is now Issue 18 in C26D at https://wiki.edg.com/pub/CFP/WebHome/c26d.htm. The following changes address the problem.

In 7.12 #4 change

They are present only if the implementation defines __STDC_IEC_60559_DFP__ and additionally the user code defines __STDC_WANT_IEC_60559_EXT__ before any inclusion of <math.h>.

to

They are present only if the implementation defines __STDC_IEC_60559_DFP__ before any inclusion of <math.h>.

In 7.12 #6 change

The macros in this paragraph are only present if the implementation defines __STDC_IEC_60559_DFP__ and additionally the user code defines __STDC_WANT_IEC_60559_EXT__ before any inclusion of <math.h>.

to

The macros in this paragraph are only present if the implementation defines __STDC_IEC_60559_DFP__ before any inclusion of <math.h>.

In B.11 change

Only if the implementation defines __STDC_IEC_60559_DFP__ and additionally the user code defines __STDC_WANT_IEC_60559_EXT__ before any inclusion of <math.h>: ...

to

Only if the implementation defines __STDC_IEC_60559_DFP__ before any inclusion of <math.h>: ...

Make changes to the Index entries for 

__STDC_WANT_IEC_60559_EXT__
and
__STDC_WANT_IEC_60559_EXT__ macro

to reflect the changes above.

- Jim Thomas

> On Feb 16, 2024, at 2:43 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> Here's another one to be added to CFP's C2Y issues list.
> 
> - Jim Thomas
> 
>> Begin forwarded message:
>> 
>> From: Joseph Myers <josmyers at redhat.com>
>> Subject: [SC22WG14.24752] __STDC_WANT_IEC_60559_EXT__ and DFP interfaces
>> Date: February 15, 2024 at 12:43:12 PM PST
>> To: sc22wg14 at open-std.org
>> 
>> The following is a technical issue, so *not* something that can be 
>> addressed now for C23, or indeed for C2y until we have a paper, or an 
>> issue tracker with a relevant issue in it (it's now the 11th item on my 
>> list of things to file in an issue tracker once we have one, as I think it 
>> will be appropriate to handle through such an issue-handling mechanism), 
>> but CFP should probably look at it.
>> 
>> Some decimal floating-point interfaces in <math.h> are conditional on the 
>> user defining __STDC_WANT_IEC_60559_EXT__, but others aren't.  
>> Specifically, _Decimal32_t, _Decimal64_t, HUGE_VAL_D32, HUGE_VAL_D64, 
>> HUGE_VAL_D128 are conditional on the user defining that macro, while 
>> DEC_INFINITY, DEC_NAN, FP_FAST_* for decimal types, and all functions 
>> other than those in Annex F are not.
>> 
>> I don't think this division of dependency on that macro makes sense.  My 
>> understanding of the intent of what was agreed after the October 2020 
>> discussion of N2570 was that only the interfaces defined in Annex F should 
>> be conditional on __STDC_WANT_IEC_60559_EXT__ - that is, the totalorder 
>> and payload functions and CR_DECIMAL_DIG, but the decimal interfaces 
>> enumerated above should not be so conditional.  (FE_SNANS_ALWAYS_SIGNAL is 
>> in Annex F but *not* conditional on __STDC_WANT_IEC_60559_EXT__.  Since 
>> FE_* is a reserved namespace for <fenv.h>, I think that's fine.)
>> 
>> -- 
>> Joseph S. Myers
>> josmyers at redhat.com
>> 
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240406/cb903d99/attachment-0001.htm>


More information about the Cfp-interest mailing list