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

["Rob Wilton (rwilton)" <[e-mail]>]

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

> From: Carsten Bormann <[e-mail]>

> Sent: 15 January 2020 17:07

> To: Rob Wilton (rwilton) <[e-mail]>

> Cc: Michael Richardson <[e-mail]>; [e-mail]

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

>

> OK, let’s get pedantic then.

[RW]

I am not being pedantic. 😉



CPU architectures really do not natively support negative 64 bit integers, and you can't pretend that they do, so let's just avoid them, because we don't need them and they will only cause bugs/mistakes.





>

> The operation that would be needed here without the 63-bit restriction is

> adding a 65-bit signed (delta) to a 64-bit unsigned (context SID), with

> the constraint that the result (actual SID) fits into a 64-bit unsigned.

> Unless you want to do error checking (which probably is a good idea), this

> can be done entirely with 64-bit unsigned numbers, simply ignoring the

> modulo wraparounds.  Error checking then just requires a few magnitude

> checks, which do require some scribbling on the back of an envelope to get

> right.

[RW]



I've not said that one can't encode this, just that it becomes more tricky and I predict that people will get it wrong, or likely assume that SIDs are only 63 bits.



E.g. when constructing the SID delta (in C) you can't just subtract the child SID from the parent SID and convert to a cbor signed/unsigned value, and expect the right thing to happen.  You have further annoyances if you want to store the SID deltas in heap data structures for any reason.  Perhaps nobody will even want/need to do this, but it seems plausible that they might.





> All CPU architectures of the last 40 years (OK, maybe since the

> iAPX 432, which was 1981) that I know of make it not hard to do these

> things.

[RW]

I respectively disagree.



Having seen the hard to debug bugs when smart experienced software engineers were not careful enough with C's handling of signed and unsigned integers definitely puts me into the camp that Java got this right, and that it is unsigned arithmetic that folks struggle to consistently get right.



> Platforms like the JVM do.

>

> CBOR’s "65-bit signed" (64-bit unsigned + sign bit in mt) integer coverage

> is indeed surprising initially (it is until you start to embrace bignums).

> From the C language, implementers should be used to the fact that as soon

> as you go to "signed 64-bit" (63-bit unsigned + sign bit expressed as

> two’s complement), there are all kinds of problems.  Of course, not all C

> courses teach this…  (The main problem being that 64-bit is big enough

> that many implementers never reach the boundaries of this space.)

[RW]

Okay, but I'm of the opinion that signed types are the sane ones, and it is unsigned types that do surprising things (normally with unanticipated underflow due to subtraction and modulo arithmetic).





>

> So the problem here really is in the platform or BKAC (between keyboard

> and chair), not in the architecture...

[RW]

As per above, I think that we disagree on this point.  But really not sure it is worth spending more time on ...



Kind regards,
Rob







>

> Grüße, Carsten

>

>

> > On 2020-01-15, at 17:40, Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>> wrote:

> >

> >

> >

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

> > > From: Carsten Bormann <[e-mail]<mailto:[e-mail]>>

> > > Sent: 15 January 2020 15:46

> > > To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>

> > > Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > > 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) <[e-mail]<mailto:[e-mail]>>

> wrote:

> > > >

> > > >

> > > >

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

> > > >> From: core <[e-mail]<mailto:[e-mail]>> On Behalf Of Carsten Bormann

> > > >> Sent: 15 January 2020 13:35

> > > >> To: Michael Richardson <[e-mail]<mailto:[e-mail]>>

> > > >> Cc: [e-mail]<mailto:[e-mail]>

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

> > > >> ietf-core-sid

> > > >>

> > > >> (No chair hat.)

> > > >>

> > > >> On 2020-01-13, at 19:11, Michael Richardson

> > > >> <[e-mail]<mailto:[e-mail]>>

> > > 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

> > > >> [e-mail]<mailto:[e-mail]>

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