Re: On time64 and Large File Support

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

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

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

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