[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