Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

> -----Original Message-----

> From: Carsten Bormann <cabo@tzi.org>

> Sent: 15 January 2020 15:46

> To: Rob Wilton (rwilton) <rwilton@cisco.com>

> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; core@ietf.org

> Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

>

> Yeah, but here the problem is in the head of the implementor and not in

> the CPU architecture :-)

I'm not sure that I agree, 😉

I might be wrong, but most CPU architectures don't support 64 bit negative values (unless you move to 128 bit signed numbers with the corresponding performance overhead).  Of course, implementors can work around the architecture limitations by emulating 64 bit negative numbers using unsigned 64 bit numbers ...

In fact, I was wondering whether it is really a good thing that CBOR allows a 64 bit negative integer to be expressed.  It means that the CBOR encoding can easily carry values that most implementations cannot easily generate or represent.

So, I looked at the first available C implementation example at https://cbor.io/impls.html, and it can't handle negative 64 bit numbers, overflowing them into a long variable.  I wonder what proportion of CBOR implementations do handle these correctly ...  Of course, I'm not suggesting changing the spec, just a retrospective observation.

> I was not suggesting the text behind the

> substitutes to be included, this was just explanation why I’d like to have

> the change.

[RW]

Yes, but I think that "architectures" is probably the correct term here, at least until we end up with CPUs with a 65 bit signed datapath, although I have to confess that I doubt that the choice of word really matters. 😊

Thanks,
Rob

>

> Grüße, Carsten

>

>

> > On 2020-01-15, at 16:01, Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:

> >

> >

> >

> >> -----Original Message-----

> >> From: core <core-bounces@ietf.org<mailto:core-bounces@ietf.org>> On Behalf Of Carsten Bormann

> >> Sent: 15 January 2020 13:35

> >> To: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>

> >> Cc: core@ietf.org<mailto:core@ietf.org>

> >> Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

> >>

> >> (No chair hat.)

> >>

> >> On 2020-01-13, at 19:11, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>

> wrote:

> >>>

> >>> The use of 63-bit unsigned integers allows SIDs to be manipulated

> >>> more easily  on architectures that might otherwise lack native

> >>> 64-bit

> >> unsigned arithmetic.

> >>> The loss a single bit of precision is not significant given the size

> >>> of the  space.

> >>

> >> s/use of/limitation to/     (we have been using them before)

> >> s/architectures/platforms/  (Java is our main problem here, no?)

> > [RW]

> > I think that it would be awkward for most languages/CPU architectures,

> anywhere where you could end up with a negative number that is less than

> 2^63.

> >

> > Yes, it is possible to write code in C or Java to handle this, but my

> > hunch is that implementations could easily get this wrong (e.g. by

> > just using signed int64 as the type to hold the difference between

> > parent and child SIDs.)

> >

> > Thanks,

> > Rob

> >

> >

> >> s/precision/range/ s/space/remaining space/

> >>

> >> Grüße, Carsten

> >>

> >> _______________________________________________

> >> core mailing list

> >> core@ietf.org<mailto:core@ietf.org>

> >> https://www.ietf.org/mailman/listinfo/core