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.
