Re: On time64 and Large File Support

[Sam James]

> On 30 Dec 2022, at 22:12, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> 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.
> 

I think it's useful as a primitive to have (some projects may want to use it to 
clearly define what they don't support) but I understand why you won't be using 
it for those projects.

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

I think we might benefit from a page on the glibc wiki or something describing 
our broad vision & what distributions and upstreams need to know but that's not 
a blocker and it's a nice-to-have for the future.

I'm going to keep banging on about this topic once we've sorted out autoconf, 
so I don't think there's a risk in us forgetting about it.

> 
>> 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 agree broadly, but my concern is mainly in that until recently, most 
distributions (and upstream maintainers) were quite bad at finding out when ABI 
breaks occur. But things like libabigail's abidiff make this a lot easier.

Of course, the nature of ABI breakage may just mean it's a crash or 
misbehaviour which somebody never reports. But I don't want to keep rehashing 
these bits, I agree with your point below that we need to move forward.

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

I'm happy with the patch as attached. Thank you for your perseverance. 
Unfortunately, I've been running into people who are resistant
to even fix C23 issues in configure scripts in their own code because "autoconf 
is still generating broken scripts, so I'm keen to
move past the time64/LFS blockers if we can. I think this does the job.

signature.asc
Description: Message signed with OpenPGP