Re: On time64 and Large File Support

[Bruno Haible <bruno@clisp.org>]

Paul Eggert wrote:
> 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.

Paul, my assessment of Zack's proposed change is different. Things will
not "stop working". But rather, for packages
  * that have been released in the last three months, with the then-newest
    Gnulib,
  * only when this package is reconfigured with Autoconf 2.72
then
  (1) a portability problem to HP-UX/ia64 in 32-bit mode will appear,
  (2) year 2038 compliance measures will not be enabled.

(1) is not something we need to worry about, since HP-UX/ia64 has so few
users, and why should them run 'autoreconf'.

(2) is a tiny setback on our journey to year 2038 compliance. I'm saying
"tiny" because we are still 15 years away, and new releases of the (not
many) affected packages are likely to come in the next 1-2 years.

My assessment is based on the understanding that Zack's proposed change
is essentially

diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0a9adba5..649d2d17 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -278,7 +278,7 @@ AS_IF([test "$enable_largefile" != no],
          [Define for large files, on AIX-style hosts.],
          [_AC_SYS_LARGEFILE_TEST_INCLUDES])],
     [64],
-      [_AC_SYS_YEAR2038()])])
+      [])])
 
   AH_VERBATIM([__MINGW_USE_VC2005_COMPAT],
 [#if !defined __MINGW_USE_VC2005_COMPAT && defined __MINGW32__

and upon inspection of the largefile.m4 part of this Gnulib commit:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=b9bf95fd0a6ab666b484b1e224321664f051f7fa

Bruno