Re: On time64 and Large File Support

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

On 2022-11-11 18:20, Zack Weinberg wrote:

> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.

No, I was thinking about libraries as well. Although there are problems 
with libraries and time_t, for decades we've had the same problems with 
AC_SYS_LARGEFILE and off_t, rlim_t, ino_t, etc. Why should time_t be 
treated differently from the other types?


> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)

I can easily understand why glibc didn't take that approach. The LFS API 
designed in the mid-1990s to support both off_t and off64_t in 
user-level code was supposed to be a "transitional API", but we're still 
stuck with it nearly 30 years later, even though almost nobody uses it 
(and the few who do often don't use it correctly). Even if we weren't 
dissuaded by the problems of the LFS API, we won't have a luxury of a 
30-year transition for time_t, as we're only 15 years away from 2038.

More generally, the LFS API approach doesn't scale, as the complexity of 
the implementation would grow exponentially with the number of features 
involved. Nobody wants to implement or support that sort of thing. This 
is why glibc put rlimt_t, ino_t, etc. under the off_t umbrella.


> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. 

AC_SYS_LARGEFILE doesn't imply AC_SYS_YEAR2038 now, in Autoconf git. 
Things are a bit more complicated, unfortunately.