Subject: [Cbor] Decoding of 64-bit CBOR ints on 32-bit systems

From: Felipe Gasper <[email-masked]>
Date: Sat, 27 Apr 2019 17:14:30 -0400

Hello,

	Is there either a custom or a standard that guides interpretation of 64-bit CBOR integers on 32-bit systems that don’t have 64-bit emulation?

	Thank you!

-Felipe Gasper
Mississauga, Ontario

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Apr 2019 00:06:30 +0200

Hi Felipe,

> On Apr 27, 2019, at 23:14, Felipe Gasper <[email-masked]> wrote:
> 

How to interpret this question depends a bit on what you are trying to do.  Let me try to list the possibilities:

(1) I have an application protocol that makes use of integers that don’t fit into the 32-bit integers I have on my systems.

(2) I have an application protocol that doesn’t make use of such integers.  A CBOR encoder could still use a 64-bit form for such an integer (non-preferred encoding).

Orthogonal to this is the question whether you are employing a generic CBOR decoder or an application-specific one.

I think for (2) with a generic CBOR decoder, my recommendation would be to handle this in the generic CBOR decoder (e.g., by checking that the upper 32 bits are zero); similarly for an application specific CBOR decoder.  Alternatively, the application protocol could outright forbid 64-bit forms, just like it could forbid floating point numbers.

For (1), any application-specific CBOR decoder would then have to handle this case in a way that makes sense for the application.  A generic CBOR decoder could define its own 64-bit integer type (not necessarily with all the usual operations implemented), e.g. as a struct of two 32-bit unsigned integers.  Such a generic decoder would, of course, also work for (2); I’d probably still recommend that the decoder deliver integers where the upper half is zero as simple 32-bit integers.  An application of type (2) would handle any input that has those 64-bit structures as “unexpected” input.

Similar considerations apply for other data types not supported by the platform, e.g. 64-bit floating point values (or floating point values at all); it is maybe more obvious how to handle these.

After trying to handle your question in a general way, I think you can see what we would like to know about the specific circumstances to really answer this question.

Grüße, Carsten

---

From: Felipe Gasper <[email-masked]>
Date: Sat, 27 Apr 2019 19:19:40 -0400

> On Apr 27, 2019, at 6:06 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Felipe,
> 

Hi Carsten,

Thank you for your response. Please forgive my vagueness before.

I’m writing a general-purpose CBOR library in Perl XS. (The existing one doesn’t support newer Perl versions and has licensing problems for my team.)

I think what makes the most sense for me will be to consider numbers that aren’t representable in 32 bits as invalid input.

Thank you again!

-FG

p.s. The project is up at: https://github.com/FGasper/p5-CBOR-Free

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Apr 2019 10:12:49 +0200

> I think what makes the most sense for me will be to consider numbers that aren’t representable in 32 bits as invalid input.

Another alternative would be to represent these numbers using any bignum facility that may be part of the language (or popular – I must admit I’m not using Perl as much today as I did in the 1990s, so I’m not sure which such facility you would use).  This by the way also could then be used to handle tags 2/3.

Grüße, Carsten