[cfp-interest 3884] Re: convertFrom and signaling NaNs

[RAJAN BHAKTA]

Hi Jan,

I was giving a specific case of value, but the general case I believe holds: The value of a NaN (signaling or otherwise) is a NaN (not a number). The signaling or quiet aspects are not a part of the value. i.e. Section 6.3.2.5 “Real Floating Types" is concerned with value preservation (e.g., 3.14 remains 3.14, infinity remains infinity, NaN remains NaN), not with preserving the signaling/quiet distinction. So the “precise meaning of an object” is that it’s a NaN. Essentially this is similar to how various non-canonical representations can all represent the same value, including ones that provide additional information outside of the value.

I can see we disagree on this part, and hence it may make sense to make a change to the standard to make it clear/explicit.


Regards,

Rajan Bhakta
CFP



From: Jan Schultke <janschultke at googlemail.com>
Date: Thursday, April 16, 2026 at 2:36 PM
To: RAJAN BHAKTA <rbhakta at us.ibm.com>
Cc: cfp-interest at oakapple.net <cfp-interest at oakapple.net>
Subject: [EXTERNAL] Re: convertFrom and signaling NaNs

This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-XFVHHo80mE1PTx5QApOe0MNwyUrt8VlzhzyXnGn4Y8_94nA7bR9HcQ1oehNyiAE3Gw7otUUz_hDMhyC04yy7R0Sd-8A4pRdkMHubMqr580uF4xrI1ioZLjfiA$>


Hi,

How to handle issues for C (WG14) are given at https://www.open-std.org/jtc1/sc22/wg14/issues/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.open-2Dstd.org_jtc1_sc22_wg14_issues_&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XTIN0AwPKAf2bIKNxlzdeqggAytE5h-JEusWpx9MXwc&m=Q07maytVJxXWrqyVGB6sEg51yjqEWSF2wU7ccFJXUClAAvfsz6thR6JHnA7eKU3N&s=tNvLT0zA5tU8F2RRX6RwWm3s91cp_o_OPU-YGZEcT84&e=>. Essentially you need to email the issue to c-issues at open-std.org<mailto:c-issues at open-std.org>.

Thanks, I can do that, but first let's make sure we're on the same page.
For this particular issue, I believe the value for the SNaN is the payload and that is unchanged. The operation still raises “invalid” as expected from any operation (including conversion) other than the very small set that explicitly do not do so (ex. The issignaling macro).

Firstly, ISO/IEC 60559 merely recommends that NaN payloads are propagated. §6.2.3 is full of "should". It would be extremely surprising if the C requirement EVEN for implementations that don't conform to Annex F was stricter than ISO/IEC 60559. That can't be right, but the wording says the value is unchanged, and you're reading "value" as synonymous with NaN payload.

Secondly, I don't know why you would read that as being synonymous here. "value" as defined in §3.24 is the "precise meaning of the contents of an object when interpreted as having a specific type". It's a C construct derived from contents of an object, so when the C wording requires that a "value" is unchanged, I'm reading that as an sNaN not turning into a qNaN since those are two different values. However, the underlying hardware operation does turn sNaNs into qNaNs, and so does the convertFormat operation in ISO/IEC 60559, so I'm not finding any way to read the C wording as non-defective.

Anyway, I'm not really an expert, so I'd be happy if you could elaborate on this before I go and report to someone else :)


Yours
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260416/3b5cecb8/attachment-0001.htm>