On Wed, Jul 23, 2008 at 02:41:14PM +0000, Johannes Schindelin wrote: > Hi, > > On Wed, 23 Jul 2008, Björn Steinbrink wrote: > > > diff --git a/index-pack.c b/index-pack.c > > index ac20a46..33ba8ef 100644 > > --- a/index-pack.c > > +++ b/index-pack.c > > @@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack( > > write_or_die(output_fd, header, n); > > obj[0].idx.crc32 = crc32(0, Z_NULL, 0); > > obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n); > > + obj[0].hdr_size = n; > > + obj[0].type = type; > > + obj[0].size = size; > > obj[1].idx.offset = obj[0].idx.offset + n; > > obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0]..idx.crc32); > > hashcpy(obj->idx.sha1, sha1); > > I confirm that the issues I saw went away with this patch, and it looks > obviously like the correct approach. > > The only things valgrind is still complaining about (apart from libz, > which I will not bother commenting about) are uninitialized parts of the > data being written to disk, and a crc over them. > > Judging from the addresses, those are probably the bytes that are padded > for 4- or 8-byte alignment, so they are probably fine. I confirm this analysis having done the same independently and reached the same conclusions.
Attachment:
pgpU1dntBG299.pgp
Description: PGP signature
