Re: On time64 and Large File Support

[Paul Eggert <eggert@cs.ucla.edu>]

On 2022-11-12 06:16, Zack Weinberg wrote:
> I am going to go ahead and do this if nobody raises a concrete objection
> within the next 24 hours.

I object to a simple reversion, as this will cause problems downstream 
with Gnulib-using applications, several of which have already been 
released assuming the current Autoconf git will go into the next 
release, and which will stop working if built from Git with an Autoconf 
2.72 where the AC_SYS_LARGEFILE changes have been reverted. Current 
Gnulib assumes that AC_SYS_LARGEFILE will behave in Autoconf 2.72 like 
what's in Git now. If we change AC_SYS_LARGFILE back, we will need to 
change Gnulib too, and update downstream apps accordingly.

Instead, I suggest a partial reversion, in which AC_SYS_LARGEFILE goes 
back to its previous meaning by default, but there is a well-documented 
way to get the current in-Git meaning, a way that Gnulib can recognize 
and use. For example, you'd get the new meaning if you configure with 
--enable-year2038, or if configure.ac uses a new macro 
AC_SYS_LARGER_FILE that supersedes AC_SYS_LARGEFILE. This will also 
require some Gnulib changes, but they'll be more reliable and stable 
than whipsaw changes required by reverting then whatever future changes 
Autoconf makes.

This proposal would resolve the backward-compatibility concerns for 
people who want to delay worrying about year-2038 issues, while also 
resolving the compatibility concerns of Gnulib. It would also provide a 
better-documented way for distros that want to switch to 64-bit time_t.

Of course this sort of thing cannot be written and tested in an hour. 
But reverting is not that simple either, and would be a less efficient 
use of everybody's time.