Re: On time64 and Large File Support

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

On 2022-11-11 00:38, Sam James wrote:
> All that to say, I don't propose making these options unconditional,
> because I think the boat has sailed as of glibc-2.34 [4], and I think
> it's fair that autoconf keep the behaviour as described in git master
> right now given the situation with glibc, but I don't think it's
> a wise path for most distributions to follow.
As a practical matter, I expect that each distro will have to do a 
big-bang move, assuming the distro want to support traditional 32-bit 
platforms at all. It makes little sense to try to have some programs and 
libraries with 32-bit time_t, while others have 64-bit time_t. Just 
switch to 64-bit time_t everywhere.

This is not something distros can put off for long. We're only 15 years 
from when 32-bit time_t stops working. If distros plan to to support 
traditional 32-bit platforms, they really need to do the big-bang move 
soon. They can do it by predefining _TIME_BITS=64 and 
_FILE_OFFSET_BITS=64, or by using the new Autoconf macros, or whatever.

One possible way forward would be for glibc to change its defaults for 
_FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. 
This would make it easier to do a big-bang switch, which is what people 
need to do anyway. The backward-compatibility argument for defaulting 
these to 32 is making less and less sense as time goes on.