[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On time64 and Large File Support

From: Paul Eggert
Subject: Re: On time64 and Large File Support
Date: Sat, 12 Nov 2022 10:19:17 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]