<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>I recently came across a similar question related to conditionals in Annex H. The draft I am reading states:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p>An implementation that defines __STDC_IEC_60559_TYPES__ to 202311L shall conform to the<br />specifications in this annex. An implementation may define __STDC_IEC_60559_TYPES__ only if it<br />defines __STDC_IEC_60559_BFP__, indicating support for ISO/IEC 60559 binary floating-point arith-<br />metic, or defines __STDC_IEC_60559_DFP__, indicating support for ISO/IEC 60559 decimal floating-<br />point arithmetic (or defines both).</p>
</blockquote>
<p>And later:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p>An implementation that defines __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_TYPES__ shall<br />provide _Float32 and _Float64 as interchange floating types with the same representation and<br />alignment requirements as float and double, respectively.</p>
</blockquote>
<p>This makes it sound like __STDC_IEC_60559_TYPES__ is the test macro for compliant _FloatN types, but couples that compliance (w.r.t. the macro) to the behavior of float and double. This means that platforms where float and double are not binary32 and binary64, such as AVR, are not able to indicate compliant Annex H types.</p>
<p>Similarly, those platforms cannot define __STDC_IEC_60559_BFP__ and thus cannot provide getpayload et al.</p>
<p>Perhaps guiding toward standard float and double representations is the intent, but it seems preferable to decouple that from Annex H support. As-is, the _FloatN utility of cross-platform consistency is somewhat weakened if they can't be fully defined on the inconsistent platforms.</p>
<p>- Trevor</p>
<p id="reply-intro">On 2026-05-11 13:14, RAJAN BHAKTA wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: #000000;">Another item from WG14 that will be added to our Agenda for the May meeting.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: #000000;"> </div>
<div id="v1ms-outlook-mobile-signature">
<p class="v1xxmsonormal" style="margin: 0in;"><span style="color: #212121;">Regards,<br /><br /><strong>Rajan Bhakta</strong><br /></span> </p>
</div>
<div id="v1mail-editor-reference-message-container">
<div class="v1ms-outlook-mobile-reference-message v1skipProofing"> </div>
<div class="v1ms-outlook-mobile-reference-message v1skipProofing" style="text-align: left; padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: #b5c4df currentcolor currentcolor; font-family: Aptos; font-size: 12pt; color: black;"><strong>From: </strong>owner-sc22wg14@open-std.org <owner-sc22wg14@open-std.org> on behalf of Joseph Myers <josmyers@redhat.com><br /><strong>Date: </strong>Monday, May 11, 2026 at 11:45 AM<br /><strong>To: </strong>sc22wg14@open-std.org <sc22wg14@open-std.org><br /><strong>Subject: </strong>[EXTERNAL] [SC22WG14.36469] Annex H and non-arithmetic interchange formats<br /><br /></div>
<div class="v1PlainText" style="font-size: 11pt;">I don't think I've seen any comments from CFP on this issue I raised in<br />October. Maybe CFP missed this message?<br /><br />--<br />Joseph S. Myers<br />josmyers@redhat.com<br /><br />On Thu, 23 Oct 2025, Joseph Myers wrote:<br /><br />> Some of the rules in Annex H for when functions should be declared,<br />> conditional on support for non-arithmetic interchange formats, seem rather<br />> odd. Are these rules as intended or is there a mistake here?<br />><br />> H.11.4.1 says "Implementations that do not support non-arithmetic<br />> interchange formats are not required to declare the functions in this<br />> subclause." (that is, the encoding conversion functions; I think "this<br />> subclause" must mean H.11.4). Obviously that makes sense for such<br />> functions *for such non-arithmetic formats*. But what about such<br />> functions for arithmetic formats?<br />><br />> * encodefN and decodefN use the _FloatN type; that is, they only make<br />> sense for arithmetic formats. But they're in H.11.4, suggesting that in<br />> the absence of non-arithmetic formats, those functions need not be<br />> supported for arithmetic formats either. Furthermore, the corresponding<br />> functions for decimal types have no such restriction.<br />><br />> * fMencfM, dMencdecdN and dMencbindN are described in H.11.4.3.1 as being<br />> declared for all supported pairs of (unequal) M and N, both arithmetic and<br />> non-arithmetic. But the above quoted statement would suggest that in the<br />> absence of non-arithmetic formats, none of them are supported even for<br />> arithmetic formats.<br />><br />> * The string-from-encoding and string-to-encoding functions in H.12.4 and<br />> H.12.5 also apply for both arithmetic and non-arithmetic formats. But as<br />> they aren't part of H.11.4, the wording from H.11.4.1 doesn't apply to<br />> them. So those functions, unlike the direct encoding conversion<br />> functions, seem to be required for all supported arithmetic formats<br />> regardless of whether any non-arithmetic formats are supported.<br />><br />> --<br />> Joseph S. Myers<br />> josmyers@redhat.com<br /><br /></div>
</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />cfp-interest mailing list<br /><a href="mailto:cfp-interest@oakapple.net">cfp-interest@oakapple.net</a><br /><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest" target="_blank" rel="noopener noreferrer">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></div>
</blockquote>
<p><br /></p>
</body></html>