Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

From: Jeff King <peff@peff.net>
Date: Jul 14, 2016, 18:24 UTC
Message-ID: <20160714182427.GC16497@sigill.intra.peff.net>
In-Reply-To: <19a2d02e-3918-3bc9-db34-66e12ab950e4@kdbg.org>

On Thu, Jul 14, 2016 at 06:45:47PM +0200, Johannes Sixt wrote:

Show 17 quoted lines

> Am 14.07.2016 um 17:47 schrieb Johannes Schindelin:
> > On Thu, 30 Jun 2016, Jeff King wrote:
> > > The ustar format only has room for 11 (or 12, depending on
> > > some implementations) octal digits for the size and mtime of
> > > each file. For values larger than this, we have to add pax
> > > extended headers to specify the real data, and git does not
> > > yet know how to do so.
> > > 
> > > [...]
> > >  t/t5000/19f9c8273ec45a8938e6999cb59b3ff66739902a | Bin 0 -> 2048 bytes
> > 
> > It appears that this blob cannot be read when sizeof(unsigned long) == 4.
> > This happens to break the t5000 test on Windows, where that comparison
> > holds true.
> 
> The problem occurs in parse_sha1_header_extended(), where the calculation of
> the size in the object header overflows our 32-bit unsigned long.

Yep, unsurprising.

I do think git is wrong to use "unsigned long" there. It really ought to be "size_t". My understanding is that 64-bit Windows is LLP64, which means that you cannot currently have blobs greater than 4GB there, even though it would work correctly with size_t.

Switching all of the things that look at blob sizes to size_t will be a big job, though.

-Peff