Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

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

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On 7/5/21 6:34 PM, Bruno Haible wrote:

> What are these appropriate flags?

It was "./configure TIME_T_32_BIT_OK=yes". Though this wasn't documented 
well and perhaps needed other options, and it's different in style from 
how largefile worked.

> I'd like to understand
>    - whether these flags are simple or complicated,

They should be simple.

>    - whether we really do need a module dependency 'largefile' -> 'year2038',
>    - how to best document these things.

It shouldn't be a module dependency, since year2038 means "I must have 
64-bit time_t or I won't build" whereas largefile merely means "I want 
the widest off_t/dev_t/ino_t/time_t available". That being said, 
largefile can use some of the year2038 macros.

> we need an
>   AC_ARG_ENABLE([year2038], ...)
> like we already have an
>   AC_ARG_ENABLE([largefile], ...)

Yes, something like that would be better than the TIME_T_32_BIT_OK flag.

I installed the attached patches into Gnulib to implement the above 
suggestions. The first one is just a doc fix; the second one does the 
real work.

[-- Attachment #2: 0001-doc-clarify-which-module-fixes-32-bit-time_t.patch --]
[-- Type: text/x-patch, Size: 2189 bytes --]

From 8d8007df5e302f7f74faefc0f87983adbbc1c8c8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 6 Jul 2021 15:08:05 -0700
Subject: [PATCH 1/2] doc: clarify which module fixes 32-bit time_t

* doc/posix-headers/time.texi: Make it clear that the 32-bit
time_t problem is addressed by the year2038 module, not
by the time module.
---
 ChangeLog                   |  7 +++++++
 doc/posix-headers/time.texi | 16 ++++++++++------
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b00dfd1fd..3cd55e5ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2021-07-06  Paul Eggert  <eggert@cs.ucla.edu>
+
+	doc: clarify which module fixes 32-bit time_t
+	* doc/posix-headers/time.texi: Make it clear that the 32-bit
+	time_t problem is addressed by the year2038 module, not
+	by the time module.
+
 2021-07-01  Paul Eggert  <eggert@cs.ucla.edu>
 
 	year2038: support glibc 2.34 _TIME_BITS=64
diff --git a/doc/posix-headers/time.texi b/doc/posix-headers/time.texi
index b9be347c7..3d8164645 100644
--- a/doc/posix-headers/time.texi
+++ b/doc/posix-headers/time.texi
@@ -8,12 +8,6 @@ Gnulib module: time
 Portability problems fixed by Gnulib:
 @itemize
 @item
-On some platforms where @code{time_t} defaults to 32-bit but can be
-changed to 64-bit, functions like @code{stat} can fail with
-@code{errno == EOVERFLOW} when a 32-bit timestamp is out of range,
-such as with a file timestamp in the far future or past:
-glibc 2.34.
-@item
 @samp{struct timespec} is not defined on some platforms.
 @item
 The macro @code{TIME_UTC} is not defined on many platforms:
@@ -24,6 +18,16 @@ expressions:
 NetBSD 5.0.
 @end itemize
 
+Portability problems fixed by the Gnulib module @code{year2038}:
+@itemize
+@item
+On some platforms where @code{time_t} defaults to 32-bit but can be
+changed to 64-bit, functions like @code{stat} can fail with
+@code{errno == EOVERFLOW} when a 32-bit timestamp is out of range,
+such as with a file timestamp in the far future or past:
+glibc 2.34.
+@end itemize
+
 Portability problems not fixed by Gnulib:
 @itemize
 @item
-- 
2.30.2


[-- Attachment #3: 0002-year2038-Add-disable-year2038-option.patch --]
[-- Type: text/x-patch, Size: 6414 bytes --]

From 12169c73bc0008553e6786cd8ef39ccf28cc1519 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 6 Jul 2021 15:21:44 -0700
Subject: [PATCH 2/2] year2038: Add --disable-year2038 option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also, document this stuff better.  Suggested by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2021-07/msg00011.html
* doc/year2038.texi: Document --disable-year2038.
* m4/year2038.m4 (gl_YEAR2038_BODY): Support ‘./configure
--disable-year2038’ to disable 64-bit time_t when that is not the
default.  Arg is now either empty or nonempty (not a shell
command) and is evaluated at m4 expansion time instead of at
runtime; all callers changed.
---
 ChangeLog         | 10 ++++++++++
 doc/year2038.texi | 19 +++++++++++++++++--
 m4/largefile.m4   |  2 +-
 m4/year2038.m4    | 23 ++++++++++++++---------
 4 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3cd55e5ba..2eaf00b59 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
 2021-07-06  Paul Eggert  <eggert@cs.ucla.edu>
 
+	year2038: Add --disable-year2038 option
+	Also, document this stuff better.  Suggested by Bruno Haible in:
+	https://lists.gnu.org/r/bug-gnulib/2021-07/msg00011.html
+	* doc/year2038.texi: Document --disable-year2038.
+	* m4/year2038.m4 (gl_YEAR2038_BODY): Support ‘./configure
+	--disable-year2038’ to disable 64-bit time_t when that is not the
+	default.  Arg is now either empty or nonempty (not a shell
+	command) and is evaluated at m4 expansion time instead of at
+	runtime; all callers changed.
+
 	doc: clarify which module fixes 32-bit time_t
 	* doc/posix-headers/time.texi: Make it clear that the 32-bit
 	time_t problem is addressed by the year2038 module, not
diff --git a/doc/year2038.texi b/doc/year2038.texi
index de85bc6d2..213fda235 100644
--- a/doc/year2038.texi
+++ b/doc/year2038.texi
@@ -6,5 +6,20 @@ that will likely occur in the year 2038, for programs that use a 32-bit
 @samp{time_t} type.  See @url{https://en.wikipedia.org/wiki/Year_2038_problem}
 for details.
 
-The gnulib module @samp{year2038} attempts to avoid this problem, by
-ensuring that @code{time_t} is a 64-bit type.
+The Gnulib module @samp{year2038} attempts to avoid this problem, by
+ensuring that @code{time_t} is a 64-bit type and by causing
+@code{configure} to fail otherwise.
+
+The Gnulib module @samp{largefile} also attempts to avoid this problem
+when possible, because @samp{largefile} enables the widest
+file-related types supported by the system and @code{time_t} is one of
+those types.  However, @code{largefile} does not cause
+@code{configure} to fail when the year 2038 problem is not avoidable.
+
+The Gnulib @samp{largefile} and @samp{year2038} modules are
+recommended for any package that might be used after the year 2038 on
+32-bit platforms.  However, if you build such a package you can
+disable its use of 64-bit @code{time_t} by giving the
+@code{--disable-year2038} option to @code{configure}.  This may be
+useful if the package links to other libraries whose user-facing ABIs
+still require @code{time_t} to be 32-bit on your platform.
diff --git a/m4/largefile.m4 b/m4/largefile.m4
index 172a4da96..fbde5e664 100644
--- a/m4/largefile.m4
+++ b/m4/largefile.m4
@@ -116,7 +116,7 @@ AS_IF([test "$enable_largefile" != no],
          [Define for large files, on AIX-style hosts.],
          [_AC_SYS_LARGEFILE_TEST_INCLUDES])],
     [64],
-      [gl_YEAR2038_BODY([false])])])
+      [gl_YEAR2038_BODY([])])])
 ])# AC_SYS_LARGEFILE
 
 # Enable large files on systems where this is implemented by Gnulib, not by the
diff --git a/m4/year2038.m4 b/m4/year2038.m4
index 635ef124f..ad7f30358 100644
--- a/m4/year2038.m4
+++ b/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 4
+# year2038.m4 serial 5
 dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,10 @@ AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
 ----------------------------------
 AC_DEFUN([gl_YEAR2038_BODY],
 [
+ AC_ARG_ENABLE([year2038],
+   [  --disable-year2038      omit support for timestamps past the year 2038])
+ AS_IF([test "$enable_year2038" != no],
+ [
   dnl On many systems, time_t is already a 64-bit type.
   dnl On those systems where time_t is still 32-bit, it requires kernel
   dnl and libc support to make it 64-bit. For glibc 2.34 and later on Linux,
@@ -88,20 +92,21 @@ AC_DEFUN([gl_YEAR2038_BODY],
        # and 'touch' works with a large timestamp, then evidently 64-bit time_t
        # is desired and supported, so fail and ask the builder to fix the
        # problem.  Otherwise, just warn the builder.
-       if $1 \
-          && test $cross_compiling = no \
-          && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
-         rm -f conftest.time
-         AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
-       elif test "$gl_warned_about_64_bit_time_t" != yes; then
+       m4_ifval([$1],
+         [if test $cross_compiling = no \
+             && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
+            rm -f conftest.time
+            AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with '--disable-year2038'.])
+          fi])
+       if test "$gl_warned_about_64_bit_time_t" != yes; then
          AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
          gl_warned_about_64_bit_time_t=yes
        fi
       ])
-  fi
+  fi])
 ])
 
 AC_DEFUN([gl_YEAR2038],
 [
-  gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" = no])
+  gl_YEAR2038_BODY([require-64-bit])
 ])
-- 
2.30.2