[Cbor] Re: Dealing with -0.0, NaN, and Infinity

[Carsten Bormann <[e-mail]>]

On 2024-08-21, at 11:42, Anders Rundgren <[e-mail]> wrote:
> 
> When trying to define a subset of CBOR CDE suitable as a JSON replacement

➔ “a CDE application profile”  (fixed that for you)

> Although -0.0, NaN, and Infinity probably have very limited relevance in the intended target market, they must still be dealt with in some way.  The easy way is of course to just ban them during decoding.  

Which an application profile can do in its set of exclusions.

> FWIW, these are my current suggestions:
> 
> Following IEEE 754 rules it seems that -0.0 does not interfere with normal operations including comparisons; it is still treated as 0.0. So it is currently supported "as is".

(The current text in CDE does not address decode-time reductions, as they don’t make sense for deterministic encoding — that must necessarily round-trip, so all reductions are encode-time.)

> However, since mathematical operations using NaN and Infinity are somewhat less nice, and typically indicate that something is fundamentally wrong, their support is currently made optional: https://cyberphone.github.io/CBOR.js/doc/#decoder.cbor.initextended

I don’t know what “optional” means.  
Do you mean:

https://www.ietf.org/archive/id/draft-ietf-cbor-cde-05.html#appendix-A-7

> NaN with payloads are always rejected.  It is still a "strict subset" :)

All NaNs have payloads.  
I think you are talking about payloads that are non-zero.
You should probably also exclude negative NaNs, then.

> Related: since the JavaScript "JSON" object never became compatible with Open API number requirements, this became a core priority for "CBOR": https://cyberphone.github.io/CBOR.js/doc/#cbor.int.getint64

With a (presumably model-guided) pull-parser it is of course much easier to deal with the JavaScript number system.  I don’t get the question here, though.

Grüße, Carsten