[cfp-interest 3931] Fwd: [SC22WG14.36469] Annex H and non-arithmetic interchange formats

[Robert Seacord]

---------- Forwarded message ---------
From: Joseph Myers <josmyers at redhat.com>
Date: Mon, May 11, 2026 at 12:45 PM
Subject: [SC22WG14.36469] Annex H and non-arithmetic interchange formats
To: <sc22wg14 at open-std.org>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260511/117a405d/attachment-0001.htm>