Re: Best practices in regard to -D_TIME_BITS=64

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

On 1/4/22 15:33, Kaz Kylheku via Libc-alpha wrote:

> My main concern is specifically with application developers. Should
> individual applications be detecting that this is available and using it?

Yes, that's what we're doing with applications that use Gnulib. The 
Gnulib 'largefile' module morphed from its original goal of having apps 
be able to access files larger than 2 GiB, to the more-modern goal of 
being able to access files whose sizes, device numbers, inode numbers, 
and/or timestamps exceed traditional limits. Applications using the 
'largefile' module (and pretty much every Gnulib-using application uses 
the 'largefile' module) now get 64-bit time_t by default, on platforms 
that have 64-bit time_t.


> I have some apprehensions about just pulling the trigger and using it
> individually; like what if the application is included in some system
> where it is the only thing requesting that, and it causes some
> interoperability issue with other pieces.

Gnulib has behaved this way since July, and this behavior appears in the 
latest versions of coreutils, diffutils, grep, gzip and perhaps others. 
As far as I know, nobody's reported problems yet. That's of course not 
to say there won't be problems.


> One can force downstream people to deal with this. If the program
> detects that it's on a 32 bit platform where time_t is still 32 bits
> if no special compiler options are used, and where -D_TIME_BITS=64
> is available and working, the configure script can fail and make
> the user explicitly decide what they want to do: stick with the
> 32 bit time, or go to 64.

We didn't bother doing that with Gnulib; we just went with 64-bit time_t 
if available, 32-bit time_t if not.

Last year we did add a Gnulib module 'year2038' that causes 'configure' 
to fail by default if time_t is 32-bit; configurers can override that 
with './configure --disable-year2038' so that 'configure' will succeed 
even if time_t is 32-bit. Coreutils uses this module, since we didn't 
want people to build 32-bit time_t core utilities unless they explicitly 
wanted them.

People who build or use libraries that expose time_t to the API will 
likely have more issues than the abovementioned packages (time_t is like 
off_t and ino_t in that regard).


> A program not manipulating large files never needs to
> care, even if it manipulates files

Such a program will need to care, if it's compiled with 32-bit off_t and 
is linked to a 64-bit off_t library that exposes off_t to the API. 
time_t is no different from off_t here.