[Cbor] Re: nan'' application-extension literal

[Carsten Bormann <[e-mail]>]

On 5. Aug 2024, at 17:27, Thiago Macieira <[e-mail]> wrote:
> 
> I suggest using something that can be fed right back to GCC's __builtin_nan() 
> intrinsic. That is, specify the hexadecimal pattern that the NaN payload bits 
> are carrying, not an hexafloat.

That’s how I started to think about this, too.

However, the designers of the C functions nanf() and nan() made separate functions for the two floating point sizes (they don’t support half size); these two are not compatible with each other.
The reason appears to be that the designers didn’t understand that NaN payloads are left adjusted bit strings — we expect integer constants to be right adjusted (zero expand on left), not left adjusted (zero expand on right) like NaNs.
The only standard hex format that I could find for zero expand on right is hex floats.

E.g, 0x1.94p0 is "3f f9 40 00 00 00 00 00” in hex.

The corresponding NaN (obtained by flipping the first bit of the exponent), “7f f9 40 00 00 00 00 00” as double, also is "7e 50” in half precision, or "7f CA 00 00” in single precision.
These three sizes convert freely between each other.
In my proposed notation, they all are represented as nan’0x1.94p0’.
In C, I think they are something like nan(0x1400000000000) or nanf(0x4A0000).
That doesn’t make a lot of sense if we try to express values independent of their representation size (and encourage preferred encoding).

(The C language functions are also missing a way to create signaling NaNs.)

Toggling the msb of the exponent (as in value.b[0] ^= 0x40) is much more likely to give you what you need than the inexplicable C language functions.

Grüße, Carsten