Fixed mistype in the `VarInt` examples (#23007)

The second `VarInt` example has `0x80 0x25` is represented as (`%10000000 %00101001`) which when decoded becomes 0x1480 (5248)

When trying to implement `VarInt` encoding and decoding myself I found that `0x25` is actually `%00100101` instead of `%00101001` which causes the final decoded `VarInt` to be incorrect.

The proper hex value for the binary `%00101001` is `0x29`
This commit is contained in:
Luke Pfeiffer 2020-06-16 13:07:41 -07:00 committed by GitHub
parent b6bde6cbc9
commit 89e387ee88
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions

View File

@ -941,7 +941,7 @@ VarInt encodes the most significant bit as a marker indicating whether the byte
Examples:
* VarInt: `0x35` (`%00110101`) - the most significant bit is 0 so the value is %x0110101 i.e. 0x35 (53)
* VarInt: `0x80 0x25` (`%10000000 %00101001`) - the most significant bit of the first byte is 1 so the remaining bits (%x0000000) are the lowest bits of the value. The most significant bit of the second byte is 0 meaning this is last byte of the VarInt. The actual value bits (%x0101001) need to be prepended to the bits we already read so the values is %01010010000000 i.e. 0x1480 (5248)
* VarInt: `0x80 0x29` (`%10000000 %00101001`) - the most significant bit of the first byte is 1 so the remaining bits (%x0000000) are the lowest bits of the value. The most significant bit of the second byte is 0 meaning this is last byte of the VarInt. The actual value bits (%x0101001) need to be prepended to the bits we already read so the values is %01010010000000 i.e. 0x1480 (5248)
The biggest supported payloads are 2GB in size so the biggest number we need to support is 0x7fffffff which when encoded as VarInt is 0xFF 0xFF 0xFF 0xFF 0x07 - hence the maximum size of the length prefix is 5 bytes.