<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Here's another one to be added to CFP's C2Y issues list.<div><br></div><div>- Jim Thomas<br><div><br><blockquote type="cite"><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Joseph Myers <josmyers@redhat.com><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b>[SC22WG14.24752] __STDC_WANT_IEC_60559_EXT__ and DFP interfaces</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">February 15, 2024 at 12:43:12 PM PST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">sc22wg14@open-std.org<br></span></div><br><div><div>The following is a technical issue, so *not* something that can be <br>addressed now for C23, or indeed for C2y until we have a paper, or an <br>issue tracker with a relevant issue in it (it's now the 11th item on my <br>list of things to file in an issue tracker once we have one, as I think it <br>will be appropriate to handle through such an issue-handling mechanism), <br>but CFP should probably look at it.<br><br>Some decimal floating-point interfaces in <math.h> are conditional on the <br>user defining __STDC_WANT_IEC_60559_EXT__, but others aren't. <br>Specifically, _Decimal32_t, _Decimal64_t, HUGE_VAL_D32, HUGE_VAL_D64, <br>HUGE_VAL_D128 are conditional on the user defining that macro, while <br>DEC_INFINITY, DEC_NAN, FP_FAST_* for decimal types, and all functions <br>other than those in Annex F are not.<br><br>I don't think this division of dependency on that macro makes sense. My <br>understanding of the intent of what was agreed after the October 2020 <br>discussion of N2570 was that only the interfaces defined in Annex F should <br>be conditional on __STDC_WANT_IEC_60559_EXT__ - that is, the totalorder <br>and payload functions and CR_DECIMAL_DIG, but the decimal interfaces <br>enumerated above should not be so conditional. (FE_SNANS_ALWAYS_SIGNAL is <br>in Annex F but *not* conditional on __STDC_WANT_IEC_60559_EXT__. Since <br>FE_* is a reserved namespace for <fenv.h>, I think that's fine.)<br><br>-- <br>Joseph S. Myers<br>josmyers@redhat.com<br><br></div></div></blockquote></div><br></div></body></html>