Re: On time64 and Large File Support

Paul Eggert <[email protected]> Fri, 11 Nov 2022 11:56:04 -0800
Newsgroups dev.linux.lists.c-std-porting
Organization UCLA Computer Science Department
Message-ID <[email protected]>
On 2022-11-11 03:22, Florian Weimer wrote:

> Fortunately, any issues should be quite visibile in
> the distribution DWARF data.  If we put the time32 switch in place, we
> should be able to tell whether it's effective enough in practice.

OK, thanks; if problems turn up in that area please let the 
Autoconf/Gnulib people know what we can do to help address them.


> LFS issues have been with us for a long time, and packages and
> distributions have workarounds for it (e.g., using off64_t or long long
> in public headers).  What we have today mostly works.  But it's unknown
> whether existing AC_SYS_LARGEFILE users require any additional work for
> time64 changes.

If what we have today mostly works, then it works for blkcnt_t, dev_t, 
ino_t, off_t and rlim_t, all of whose widths differ on 32-bit x86 glibc 
depending on whether one compiles with -D_FILE_OFFSET_BITS=64. So 
there's some precedent for hoping that what we have today will mostly 
work for time_t and -D_TIME_BITS=64 as well.

In hindsight, perhaps it would have been better to have 
_FILE_OFFSET_BITS=64 also control time_t width, since that would have 
made for one less configure-time option to worry about. (After all 
rlim_t can hold 64-bit counts of seconds, so why not time_t?) I suppose 
it's too late for that now, though.