[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: Fri, 30 Dec 2022 14:12:32 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 12/28/22 20:02, Zack Weinberg wrote:

Please revert that part of your follow-up patch.
OK, I reverted all that patch, except for the further changes you requested, plus some minor quoting and version-number fixes in comments.

Is there any
chance you could send a wdiff to the list, after restoring the text
you took out because you took out the _REQUIRED variants?

Sure, I'm attaching a proposed patch to Autoconf master documentation in two forms. The first is a simple "git format-patch" file; the second is the output of "git diff --color=always --word-diff=color".

I want it to be
crystal clear from the text of that it bombed out because
package X considers 64-bit time_t and/or off_t a requirement.

Although I don't think this feature is useful, I don't have to use it so we can leave it in.

Here's why I'm not planning to use it. I help maintain (for example) GNU Tar, where file sizes and timestamps are crucial. But if I change GNU Tar to use AC_SYS_LARGEFILE_REQUIRED, people won't be able to build GNU Tar on ancient platforms that support file sizes only up to 2 GiB. Nobody will benefit from this: the very few users who'd care (computer museum curators, say) already know their systems are limited, and will simply build older versions of GNU Tar that don't use AC_SYS_LARGEFILE_REQUIRED, or will edit away the "_REQUIRED" before building. So adding the _REQUIRED will harm a very small set of users, will increase my maintenance burden a bit, and will benefit essentially nobody.

To put it another way: we've all gotten by without needing AC_SYS_LARGEFILE_REQUIRED for 25 years, and there's no reason for us to start needing it now even though it's imperative for any serious application that deals with files.

The situation for AC_SYS_YEAR2038_REQUIRED will likely be similar.

As things currently stand, I plan to use AC_SYS_YEAR2038 instead of AC_SYS_LARGEFILE in GNU Tar and similar applications. (They'll use Gnulib so they'll get Autoconf 2.72-compatible AC_SYS_YEAR2038 even with older Autoconf.) Perhaps other maintainers will want to use the *_REQUIRED macros, but as far as I can see my advice will be to avoid them as being more trouble than they're worth.

I *intended* to make it clear that they are not orthogonal in
practice, but it is not logically necessary for them to be coupled,
and it is, I think, easier to understand what
AC_SYS_{LARGEFILE,YEAR2038} do if we document them as abstractly

Unfortunately the documenation currently on Autoconf master makes for a lot of confusion and misimpression. It's more important for documentation to agree with what the code actually does, than for it to present an abstract picture of what we'd like the code to do eventually. The abovementioned patches fix this.

In the new year, I can look into the possibility of decoupling the
macros’ implementations.

I don't see how that would be possible. On the only platforms where --enable-year2038 matters, you cannot have year-2038 support without also having large-file support.

The platforms in question are glibc 2.34+ on 32-bit ARM and x86. The glibc community considered making the two things orthogonal but rejected that alternative as being considerably more trouble than it was worth. I think it unlikely for other 32-bit OS suppliers to decide differently.

I think you’re still writing documentation with application-colored
glasses on, making it sound like --enable-year2038 has no negative
implications whatsoever.

That's a bit unfair. The proposed documentation does mention the compatibility implications; it merely uses the same level of caution for both --enable-largefile and --enable-year2038, and it doesn't overhype the time_t issue with an undeserved big "Caution:" inbold.

Although I plead guilty in being close to users (many who need year 2038 support now for obvious reasons) I'm well aware of the implication for libraries. When I implemented AC_SYS_LARGEFILE back in the 1990s, there were similar compatibility concerns with off_t that I also took seriously. In the end, the need for large-file support outweighed the backward-compatibility hassles and AC_SYS_LARGEFILE has been a success in that people have used AC_SYS_LARGEFILE for years and sure there are occasionally glitches but the benefits far outweigh the costs.

AC_SYS_YEAR2038 will be similar. Not identical of course, but similar. We've done this sort of thing before and have experience.

I do not believe we have consensus
for AC_SYS_LARGEFILE to become a synonym for AC_SYS_YEAR2038, not even
“in a future Autoconf version.”

The proposed documentation patches contain a simple plan for how Autoconf can plausibly survive through the year 2038. Is there a better plan? If so, I'd like to hear it. If not, then let's use this plan. Given the long delay between Autoconf versions and end uses of downstream software, we need a plan now, not years from now. The plan doesn't have to be perfect, nor does it need to be cast in stone. But there needs to be a plan.

Attachment: 0001-Improve-year-2038-documentation.patch
Description: Text Data

Attachment: Improve-year-2038-doc-wdiff-color.txt
Description: Text document

reply via email to

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