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

From: Jeff King <peff@peff.net>
Date: Jul 14, 2016, 21:32 UTC
Message-ID: <20160714213222.GA20645@sigill.intra.peff.net>
In-Reply-To: <3d71cf3a-44c7-0620-0375-fb7ecf2fac13@kdbg.org>

On Thu, Jul 14, 2016 at 10:52:55PM +0200, Johannes Sixt wrote:

Show 19 quoted lines

> > Dscho?  I'll revert the merge of 'js/t0006-for-v2.9.2' out of
> > 'next' so that we can replace it with your newer version, but it
> > needs to be massaged to lose the strong linkage with "time", as
> > it is no longer "is our time big enough", I would think.
> 
> My first thought was that this is not warranted because t0006 is about
> commit time stamps, but the huge-tar breakage is file sizes, and the cases
> should be treated differently.
> 
> But on second thought, under the hood, both boil down to the size of
> unsigned long in our implementation. It may make sense to tie both cases to
> the same prerequisite.
> 
> On third thought, however, I think the two requirements could diverge in the
> future. The file size case should depend on the size of size_t. The
> timestamp case may become dependent on the size of time_t if we decide to
> move timestamp handling away from unsigned long: in modern(!) Microsoft
> SDKs, time_t is 64 bits, but unsigned long is 32 bits, in both the 32-bit
> and 64-bit environments!

The tar tests actually cover both: big files and big timestamps.

I think as long as the prereq is labeled LONG_IS_64BIT, we can then adjust the appropriate tests if and when they become runnable on more systems.

If we move to time_t everywhere, I think we'll need an extra TIME_T_IS_64BIT, but we can cross that bridge when we come to it.

Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit systems; LLP64 systems like Windows will then be able to run the test).

-Peff