Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Ramsay,

On Mon, 8 May 2017, Ramsay Jones wrote:

> Commit dddbad728c ("timestamp_t: a new data type for timestamps",
> 26-04-2017) introduced a new typedef 'timestamp_t', as a synonym for an
> unsigned long, which was used at the time to represent timestamps in
> git. A later commit 28f4aee3fb ("use uintmax_t for timestamps",
> 26-04-2017) changed the typedef to use an 'uintmax_t' for the timestamp
> representation type.
> 
> When building on a 32-bit Linux system, sparse complains that a constant
> (USTAR_MAX_MTIME) used to detect a 'far-future mtime' timestamp, is too
> large; 'warning: constant 077777777777UL is so big it is unsigned long
> long' on lines 335 and 338 of archive-tar.c. Note that both gcc and
> clang only issue a warning if this constant is used in a context that
> requires an 'unsigned long' (rather than an uintmax_t). (Since TIME_MAX
> is no longer equal to 0xFFFFFFFF, even on a 32-bit system, the macro
> USTAR_MAX_MTIME is set to 077777777777UL, which cannot be represented as
> an 'unsigned long' constant).
> 
> In order to suppress the warning, change the definition of the macro
> constant USTAR_MAX_MTIME to use an 'ULL' type suffix.
> 
> In a similar vein, on systems which use a 64-bit representation of the
> 'unsigned long' type, the USTAR_MAX_SIZE constant macro is defined with
> the value 077777777777ULL. Although this does not cause any warning
> messages to be issued, it would be more appropriate for this constant
> to use an 'UL' type suffix rather than 'ULL'.

	The reason for the current situation is that an earlier fix for
	the USTAR_MAX_MTIME constant was applied to the USTAR_MAX_SIZE
	constant by mistake.

> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>

With that addition to the commit message: ACK

Ciao,
Dscho