Protocol Buffers Encoding Guide erratum

[Gregory Bourassa]

Hi folks,

Has anyone noticed that the example message which begins the document is erroneous.   At one point (under the Message Structure heading) the authors claim that:

96 01 = 1001 0110  0000 0001

which it cannot,  since 1001 0110 in radix 10 is 150.  The l.h.s. of the equation should read 150 01 (as it also should in the message format at the very top of the document, which would be 08 150 01).

They go on to decode the binary part and get the correct answer.   However that only worked because the binary expression really corresponds to a l.h.s of the equation expresssed as:   150 01.     Of course that is just a bit inconvenient because it looks very much like the value they seek to decode (150)...and that coincidence that could confuse the reader;  but it happens only because the first byte must have the msb set to 1 (Varint encoding) and only the 7 lsb contain the value.   That value is 22, which when added to the 1 in the second byte, left-shifted seven places to equal 128,  yields 150.

Anyone know how to get the attention of the documentation group?

Thanks and Regards.

Gregory B.

[Ilia Mirkin]

On Thu, May 6, 2021 at 5:06 PM Gregory Bourassa
<gregory....@gmail.com> wrote:
>
> Hi folks,
>
> Has anyone noticed that the example message which begins the document is erroneous. At one point (under the Message Structure heading) the authors claim that:
>
> 96 01 = 1001 0110 0000 0001
>
> which it cannot, since 1001 0110 in radix 10 is 150.

But it's 96 in radix 16. You always use hex when talking about file /
bit encodings, never base 10...

Cheers,

-ilia

[Gregory Bourassa]

Ha ha!!!  (woops)

Thanks Ilia.   That makes total sense now.  :-)    So I gave myself a bunch of grief trying to rationalize it.

I have been accustomed to environments where only base-10 notation is unqualified,  and the others would have something such as 0x  or 16r  as a prefix.

Thanks again, and regards.

Gregory B.