[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On time64 and Large File Support

From: Paul Eggert
Subject: Re: On time64 and Large File Support
Date: Thu, 2 Mar 2023 02:28:28 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]