Re: [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB

From: Jeff King <peff@peff.net>
Date: Jul 14, 2016, 18:16 UTC
Message-ID: <20160714181637.GA16497@sigill.intra.peff.net>
In-Reply-To: <xmqq60s8rvpl.fsf@gitster.mtv.corp.google.com>

On Thu, Jul 14, 2016 at 10:11:18AM -0700, Junio C Hamano wrote:

Show 25 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > Am 30.06.2016 um 11:09 schrieb Jeff King:
> >> +/*
> >> + * This is the max value that a ustar size header can specify, as it is fixed
> >> + * at 11 octal digits. POSIX specifies that we switch to extended headers at
> >> + * this size.
> >> + */
> >> +#define USTAR_MAX_SIZE 077777777777UL
> >
> > This is too large by one bit for our 32-bit unsigned long on Windows:
> >
> > archive-tar.c: In function 'write_tar_entry':
> > archive-tar.c:295: warning: integer constant is too large for
> > unsigned long' type
> > archive-tar.c: In function 'write_global_extended_header':
> > archive-tar.c:332: warning: integer constant is too large for
> > unsigned long' type
> > archive-tar.c:335: warning: integer constant is too large for
> > unsigned long' type
> > archive-tar.c:335: warning: overflow in implicit constant conversion
> 
> Yikes.  I guess we need ULL here, and it cascade to all the
> variables used to interact with this constant, but not everybody has
> "long long", so....

On 32-bit systems, I suspect the tar limits are a non-issue. For real filesystem operations, tar on such a system would use off_t. But we use "unsigned long" internally for object sizes, so I imagine that objects larger than 4G are simply impossible on such systems.

So one option would be to simply "#if"-out these checks on 32-bit systems.

I think it would also be OK to just set USTAR_MAX_SIZE to ULONG_MAX on such a system, too (which effectively eliminates the check, but keeps the conditional bits contained).

-Peff