On Sun, Feb 10, 2019 at 07:35:38PM +0000, Ramsay Jones wrote: > > Now, the 'n-byte type and length' is a variable length encoding of > > the object type and length. The number of bytes used to encode this > > data is content dependant. If the top bit of a byte is set, then we > > need to process the next byte, otherwise we are done. So, looking > > at the first 'object entry' byte (at offset 12) '9d', we take the > > top nibble, remove the top bit, and shift right 4 bits to get the > > object type. ie. (0x9d >> 4) & 7 which gives an object type of 1 > > (which is a commit object). The lower nibble of the first byte > > contains the first (or only) 4 bits of the size, here (0x9d & 15) > > which is 0xd. Given that the top bit of this byte is set, we now > > process the next byte. After the first byte, each byte contains 7 > > bits of the size field which is combined with the value from the > > previous byte by shifting and adding (first by 4 bits, then 11, 18, > > 25 etc.). So, in this case we have (0x13 << 4) + 0xd = 317. > > Sorry, to be clear, I should have said, "mask off the top bit, > shift and add", so: > > ((0x13 & 0x7f) << 4) + 0xd = 317
Yes. Also, see the first 10 or so lines of builtin/index-pack.c's unpack_raw_entry() for real-world example code. -Peff
