Re: Confusion about the PACK format
- From
Jeff King <peff@peff.net>
- Date
- Feb 12, 2019, 00:41 UTC
- Message-ID
- <20190212004130.GI13301@sigill.intra.peff.net>
- In-Reply-To
- <a0e1ad5b-8d6b-7fa0-54f3-dc0b4b275533@ramsayjones.plus.com>
On Sun, Feb 10, 2019 at 07:35:38PM +0000, Ramsay Jones wrote:
Show 19 quoted lines
> > 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