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 was not suggesting the text behind the substitutes to be included, this was just explanation why I’d like to have the change.

Grüße, Carsten

> On 2020-01-15, at 16:01, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: core <core-bounces@ietf.org> On Behalf Of Carsten Bormann
>> Sent: 15 January 2020 13:35
>> To: Michael Richardson <mcr+ietf@sandelman.ca>
>> Cc: 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> 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
>> https://www.ietf.org/mailman/listinfo/core