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

[Jan Schultke]

> Hi,
>
> How to handle issues for C (WG14) are given at
> https://www.open-std.org/jtc1/sc22/wg14/issues/. Essentially you need to
> email the issue to 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/0c81e89f/attachment.htm>