Re: [PATCH] archive-zip: omit UT extra field if mtime is out of range

m@sph3r3.com writes:

For the i386 failure Junio reported, the beyond-2038 archive test and
its dependent omission check should use TIME_T_IS_64BIT. TIME_IS_64BIT
checks Git's timestamp_t, which can be 64-bit while time_t is 32-bit.

;-)

Thanks.  It is an obvious thing, only once it is pointed out X-<.

These two prerequisites sound too similar, and the latter probably
is no longer very relevant in the modern world, but that was what
was used in the test.

TIME_T_IS_64BIT measures how wide sizeof(time_t) is, which makes
sense as a portability test across platforms.

But TIME_IS_64BIT?  It measures how wide sizeof(timestamp_t) is, but
the thing is, it is uintmax_t everywhere as far as "git grep" can see.

        $ git grep -n -e 'typedef .*timestamp_t' :/
        compat/posix.h:267:typedef uintmax_t timestamp_t;
        $ git grep -n -e timestamp_t\; :/\*.h
        compat/posix.h:267:typedef uintmax_t timestamp_t;

So TIME_IS_64BIT can be true even if TIME_T_IS_64BIT is not.  Unless
we are on a platform where uintmax_t is 32-bit wide, TIME_IS_64BIT
would be true.  And the time value from the system that is delibered
to us initially in time_t would be limited by that even if timestamp_t
is wider.  TIME_IS_64BIT would not have much value as TIME_T_IS_64BIT
as a portability guard to tests that require wider time values across
the callstack.

Perhaps we should audit places where timestamp_t value is read from
SCM data and coerced into time_t to expose it in a form that outside
world (like ZIP archive format) would understand and warn when we
truncate values?  I will leave it as #leftoverbits for others to
think about it through ;-).

Thanks.