Re: On time64 and Large File Support

[Paul Eggert <eggert@cs.ucla.edu>]

On 2023-03-02 01:04, Daniel P. Berrangé wrote:
> IMHO if distros really want to deal with this, they need to be able to
> force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.

As things stand this is probably the best way to go. Although some pain 
is inevitable, this approach appears to be the least painful.

Mainstream developers long ago migrated to 64-bit time_t, and fewer and 
fewer of them have the time to worry about the shrinking subset of the 
embedded system world where legacy 32-bit time_t is still OK (at least 
for the next several months). It's incumbent on system builders who 
still cater to legacy 32-bit time_t (for now) to figure out how to 
wrangle their systems into the 64-bit time_t world; they can't really 
expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make the job much easier 
than it already is.


> So while there is a chance of inconsistent usage [with off_t], and thus
> ABI incompatibility, in practice this is a non-issue since everything
> of consequence has long ago opted in to _FILE_OFFSET_BITS=64.

Fifteen years from now we'll be saying the same thing about _TIME_BITS. 
There will be some pain in the meantime, just as there was with the 
_FILE_OFFSET_BITS transition, something I lived through and was not too 
happy about either.