Re: [bug-gnulib] time64: 64-bit variants of gmtime, mktime, localtime etc?

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> Paul Eggert wrote:
>> The main reason I want 64-bit time_t is so that my apps can stat any
>> file without getting EOVERFLOW. ... on 32-bit platforms
>
> If the time_t type is smaller than the type used for timestamps in the
> particular filesystem, you can get EOVERFLOW during stat().
>
> If, on the other hand, the time_t type is larger than the one used in the
> filesystem, you can get EOVERFLOW during utime().

Sure, but stat() is much, much more popular than utime().  It's used
universally, by lots of standard applications and (worse) libraries we
have no control over; in contrast, utime() is used only by a few apps
like touch, cp -p, and tar, where we do have direct control.  I'd much
rather have the utime() problem than the stat() proble.

Also, all 64-bit systems I know of use native file systems that
support 64-bit time_t.  So the utime() problem occurs only when
accessing foreign file systems.

> If a system makes the opposite choice than all other systems, it
> creates many possible bugs and security problems in various
> applications.

Sorry, I don't follow this point.  The usual combinations now are
32-bit only, 32-bit app on 64-bit host, and 64-bit app on 64-bit host.
(By "host" here I mean the combination of the OS and file system, by
"app" I mean time_t width.)

The rarer combination, which you are now bringing up, is 64-bit app on
32-bit host.  This combination already occurs in practice, though it's
rare.  Clearly it's not as good as 64-bit app on 64-bit host.  But, if
we're going to have a time_t mismatch, in practice it's better to have
this sort of mismatch than to have the 32-bit app on the 64-bit host.

I think mismatches are inevitable; we can't ask everyone to upgrade
simultaneously.  If so, I'd rather have 64-bit time_t (with its rare
problems) than 32-bit time_t (with its more-common problems).