Re: On time64 and Large File Support

[Paul Eggert]

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 configure.ac 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.

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

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