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@xxxxxxxxxxxxxxxxxxxx>
With that addition to the commit message: ACK
Ciao,
Dscho