On Thu, Jul 14, 2016 at 10:11:18AM -0700, Junio C Hamano wrote: > Johannes Sixt <j6t@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html