~sircmpwn/public-inbox

1

BARE Message Encoding

Sean Conner
Details
Message ID
<20201121093001.GB9837@brevard.conman.org>
DKIM signature
missing
Download raw message
  I just came across your BARE Message Encoding scheme, and the only comment
I have about it [1] is the lack of examples in the proposal.  The one thing
I really loved about CBOR (RFC-7049) was the large set of encoding examples
in Appendix A---there is at least one sample of every type, and for some,
multiple samples that I found valuable when creating tests when I
implemented CBOR [2].

  The two examples you gave are hard to follow, and don't cover all possible
encodings (especially the nagative int type).  I'm just going to attempt to
encode some uints and a some ints to see if I understand the descriptions. 
All values given are in hexadecimal.

  uint value	encoded
	00	00
	15	15
	7F	7F
	80	C0 00
	FF	FF 40

	0123456789ABCDEF	80 C8 E8 D6 BC A6 D7 CD F7 40

  I think, but I'm not sure, because elsewhere you list values as being
stored little endian.  So "on the wire" the table would look:

	80	00 C0
	FF	40 FF

but that can't be right, since you are using the high bit to signal
"continue".  So it's more like:

	80	80 01
	FF	FF 01
	0123456789ABCDEF	EF 9B AF CD F8 AC B1 91 81 00

  I don't know ... there's not enough examples to figure this out.  I'm
still not sure if the example for 80 is still correct.

  Now, I had to look up the "zig-zag" encoding, and from what I can see, you
can't portably write such code in C, as shifting negative values is
"implemetation defined", and shifting with negative values invokes undefined
behavior.  This page on Stack Overflow [3] goes over the potential problems
with this encoding, at least with respect to C implementations [4]:

https://stackoverflow.com/questions/4533076/google-protocol-buffers-zigzag-encoding#4533095

  I'm not even going to attempt this by hand.  And how can I determine if I
have a correct implementation if there aren't better explanations and enough
examples.

  CBOR, on the other hand, was a breeze to implement.

  -spc

[1]	Other than "What?  Yet Another Encoding Scheme?  What's wrong with
	all the other ones?"

[2]	https://github.com/spc476/CBOR

[3]	I know, I know, but it still has good information about this.

[4]	Which you may not care about, but some people do.
Details
Message ID
<C790C04L9HBW.2NRCJR241TAXC@taiga>
In-Reply-To
<20201121093001.GB9837@brevard.conman.org> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
Drop the passive agressive comments.

On Sat Nov 21, 2020 at 4:30 AM EST, Sean Conner wrote:
> I just came across your BARE Message Encoding scheme, and the only
> comment I have about it [1] is the lack of examples in the proposal.
> The one thing I really loved about CBOR (RFC-7049) was the large set
> of encoding examples in Appendix A---there is at least one sample of
> every type, and for some, multiple samples that I found valuable when
> creating tests when I implemented CBOR [2].

Aye, I intend to expand on these examples. It may also be useful to
consult the Go implementation:

https://git.sr.ht/~sircmpwn/go-bare/tree/master/example

> Now, I had to look up the "zig-zag" encoding, and from what I can see,
> you can't portably write such code in C, as shifting negative values
> is "implemetation defined", and shifting with negative values invokes
> undefined behavior. This page on Stack Overflow [3] goes over the
> potential problems with this encoding, at least with respect to C
> implementations [4]:

You should convert it to an unsigned representation first, and stash the
sign bit somewhere. This would be much easier. If you look at the next
answer after your linked SO question, it does exactly this.

> CBOR, on the other hand, was a breeze to implement.

whine whine bitch moan woe is me
Reply to thread Export thread (mbox)