Received: from brevard.conman.org (brevard.conman.org [66.252.224.242]) by mail-b.sr.ht (Postfix) with ESMTP id 1FF31FF0F2 for <~sircmpwn/public-inbox@lists.sr.ht>; Sat, 21 Nov 2020 09:30:03 +0000 (UTC) Received: by brevard.conman.org (Postfix, from userid 500) id 9446B2EA6245; Sat, 21 Nov 2020 04:30:02 -0500 (EST) Date: Sat, 21 Nov 2020 04:30:02 -0500 From: Sean Conner To: ~sircmpwn/public-inbox@lists.sr.ht Subject: BARE Message Encoding Message-ID: <20201121093001.GB9837@brevard.conman.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i 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.