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.