[cfp-interest 3928] Re: FW: [SC22WG14.36469] Annex H and non-arithmetic interchange formats

[Trevor Gross]

I recently came across a similar question related to conditionals in 
Annex H. The draft I am reading states:

> An implementation that defines __STDC_IEC_60559_TYPES__ to 202311L 
> shall conform to the
> specifications in this annex. An implementation may define 
> __STDC_IEC_60559_TYPES__ only if it
> defines __STDC_IEC_60559_BFP__, indicating support for ISO/IEC 60559 
> binary floating-point arith-
> metic, or defines __STDC_IEC_60559_DFP__, indicating support for 
> ISO/IEC 60559 decimal floating-
> point arithmetic (or defines both).

And later:

> An implementation that defines __STDC_IEC_60559_BFP__ and 
> __STDC_IEC_60559_TYPES__ shall
> provide _Float32 and _Float64 as interchange floating types with the 
> same representation and
> alignment requirements as float and double, respectively.

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.

Similarly, those platforms cannot define __STDC_IEC_60559_BFP__ and thus 
cannot provide getpayload et al.

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.

- Trevor

On 2026-05-11 13:14, RAJAN BHAKTA wrote:

> Another item from WG14 that will be added to our Agenda for the May 
> meeting.
> 
> Regards,
> 
> Rajan Bhakta
> 
> From: owner-sc22wg14 at open-std.org <owner-sc22wg14 at open-std.org> on 
> behalf of Joseph Myers <josmyers at redhat.com>
> Date: Monday, May 11, 2026 at 11:45 AM
> To: sc22wg14 at open-std.org <sc22wg14 at open-std.org>
> Subject: [EXTERNAL] [SC22WG14.36469] Annex H and non-arithmetic 
> interchange formats
> 
> I don't think I've seen any comments from CFP on this issue I raised in
> October.  Maybe CFP missed this message?
> 
> --
> Joseph S. Myers
> josmyers at redhat.com
> 
> On Thu, 23 Oct 2025, Joseph Myers wrote:
> 
>> Some of the rules in Annex H for when functions should be declared,
>> conditional on support for non-arithmetic interchange formats, seem 
>> rather
>> odd.  Are these rules as intended or is there a mistake here?
>> 
>> H.11.4.1 says "Implementations that do not support non-arithmetic
>> interchange formats are not required to declare the functions in this
>> subclause." (that is, the encoding conversion functions; I think "this
>> subclause" must mean H.11.4).  Obviously that makes sense for such
>> functions *for such non-arithmetic formats*.  But what about such
>> functions for arithmetic formats?
>> 
>> * encodefN and decodefN use the _FloatN type; that is, they only make
>> sense for arithmetic formats.  But they're in H.11.4, suggesting that 
>> in
>> the absence of non-arithmetic formats, those functions need not be
>> supported for arithmetic formats either.  Furthermore, the 
>> corresponding
>> functions for decimal types have no such restriction.
>> 
>> * fMencfM, dMencdecdN and dMencbindN are described in H.11.4.3.1 as 
>> being
>> declared for all supported pairs of (unequal) M and N, both arithmetic 
>> and
>> non-arithmetic.  But the above quoted statement would suggest that in 
>> the
>> absence of non-arithmetic formats, none of them are supported even for
>> arithmetic formats.
>> 
>> * The string-from-encoding and string-to-encoding functions in H.12.4 
>> and
>> H.12.5 also apply for both arithmetic and non-arithmetic formats.  But 
>> as
>> they aren't part of H.11.4, the wording from H.11.4.1 doesn't apply to
>> them.  So those functions, unlike the direct encoding conversion
>> functions, seem to be required for all supported arithmetic formats
>> regardless of whether any non-arithmetic formats are supported.
>> 
>> --
>> 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/20260511/4ecd7713/attachment.htm>