Re: [Cbor] 65-bit negatives, big nums conflict between CDE and dCBOR drafts?

["lgl island-resort.com" <[e-mail]>]

> On Apr 10, 2024, at 12:29 AM, Wolf McNally <[e-mail]> wrote:
> 
> LL,
> 
> It has been our intention from day one that nothing in dCBOR shall conflict with the established requirements of CBOR: all dCBOR MUST be decodable as plain CBOR, and now by extension CDE.
> 
> Further, it was never our expectation that -2^64 would be encoded as a float, and in fact we deliberately set no such expectations.

It seems so by implication. The choices are float, type 1 or tag 3. It couldn’t be type 1 because of (former) prohibition of 65-bit negatives. It couldn’t be tag 3 because that’s not part of dCBOR.

> So if dCBOR’s current proscription of type 1 negative 65-bit integers indeed conflicts with this, then it must go. Obviously, this leaves a dangling range of basic integers expressible in dCBOR that are not expressible in either signed or unsigned 64-bit machine integers and which dCBOR (indeed all CBOR) implementations that do not support wider integers will have to reject.

A lot of basic decoders like tinyCBOR return the type and the value, so they’ll return “type 1” and a “uint64”. It’s up to the app to figure out what to do next for this range of values. Apps can error out, invoke a big number library, manually handle it or maybe they don’t have to do anything put print it out or translate it to JSON.

Protocols that want to clearly and specifically spare the native code implementer trouble can do this in CDDL:
    
    xxx = int .gt -9223372036854775809

Might even be considered good CDDL hygiene to constrain the ranges of integers in a protocols.

LL