Subject: bug#29033: [platform-testers] new snapshot available: gzip-1.8.32-4606

From: Paul Eggert <[email-masked]>
Date: Mon, 6 Nov 2017 23:29:01 -0800

Bruno Haible wrote:

> + touch -t 210602070628.15 in
> touch: invalid date format '210602070628.15'
> + printf '\037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0'
> + returns_ 2 gzip -Nlv
> method  crc     date  time           compressed        uncompressed  ratio uncompressed_name
> defla 00000000 Oct 28 00:47                  20                   0   0.0% stdout
> + fail=1

Instead of suppressing the test, how about if we tell builders not to build with 
-m32 on platforms supporting 64-bit time_t? That way, they won't run into a 
problem where gzip mishandles file timestamps due to OS screwups or 
errno==EOVERFLOW problems that cannot happen with 64-bit time_t. In the 
not-too-distant future we're going to have to insist on 64-bit time_t anyway, 
and in the meantime we can strongly suggest 64-bit time_t by installing the 
first attached patch to gzip (which I've done), by installing the attached 
proposed patch to Gnulib (which I have not done yet, pending your comments), and 
by syncing gzip to gnulib.

> I think the problem is this comment:
> # On platforms that fail to support timestamps within gzip's range,
> # test that gzip warns when converting them from gzip format.
> 
> Gzip's behaviour depends on libc, and what the 'touch' program is doing
> is a different thing. It's incorrect to assume that libc's behaviour and
> touch's behaviour are consistent.

The testcase doesn't assume that. It merely assumes that standard utilities 
support a superset of the timestamps that libc supports. This should be a 
reasonable assumption for the -m32 case that you describe (and which I'm trying 
to discourage with the abovementioned patches).

The assumption would not be reasonable for platforms where standard utilities 
are worse than libc, but this should be uncommon. If it is a problem, perhaps we 
can get by, by simply telling users to ignore the tests in that case.

CC'ing to bug-gnulib since the 2nd patch is for Gnulib.
From bca6ab306d2940e63f2cb1252968310d8f40d31c Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Mon, 6 Nov 2017 23:14:40 -0800
Subject: [PATCH] misc: diagnose year-2038 configuration problems

* bootstrap.conf (gnulib_modules): Add year2038.
* m4/.gitignore: Add year2038.m4[
---
 bootstrap.conf | 1 +
 m4/.gitignore  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/bootstrap.conf b/bootstrap.conf
index bea50e4..b973839 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -61,6 +61,7 @@ update-copyright
 utimens
 verify
 xalloc
+year2038
 yesno
 '
 
diff --git a/m4/.gitignore b/m4/.gitignore
index 9216223..2aecca5 100644
--- a/m4/.gitignore
+++ b/m4/.gitignore
@@ -149,3 +149,4 @@
 /xsize.m4
 /yesno.m4
 /host-cpu-c-abi.m4
+/year2038.m4
-- 
2.13.6

From 9e78a57ae30ec897241ea3200ca767b622539f2b Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Mon, 6 Nov 2017 23:20:23 -0800
Subject: [PATCH] year2038: be more insistent about 64-bit time_t

Applications requiring access to arbitrary files should not be
built with 32-bit time_t on hosts that have 64-bit timestamps,
as this can lead to real trouble at runtime.
* m4/year2038.m4 (gl_YEAR2038): Do not require AC_CANONICAL_HOST.
Check on all systems, not just MinGW.  Use a heuristic involving
TIME_T_32_BIT_OK, cross_compiling, and the touch command to
output a failure or just a warning, to make it more likely that
builders will select 64-bit time_t.
---
 ChangeLog      | 12 ++++++++++++
 m4/year2038.m4 | 36 ++++++++++++++++++++----------------
 2 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c9dc192dd..cad5ed70d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2017-11-06  Paul Eggert  <[email-masked]>
+
+	year2038: be more insistent about 64-bit time_t
+	Applications requiring access to arbitrary files should not be
+	built with 32-bit time_t on hosts that have 64-bit timestamps,
+	as this can lead to real trouble at runtime.
+	* m4/year2038.m4 (gl_YEAR2038): Do not require AC_CANONICAL_HOST.
+	Check on all systems, not just MinGW.  Use a heuristic involving
+	TIME_T_32_BIT_OK, cross_compiling, and the touch command to
+	output a failure or just a warning, to make it more likely that
+	builders will select 64-bit time_t.
+
 2017-11-05  Paul Eggert  <[email-masked]>
 
 	havelib: fix typo in previous change
diff --git a/m4/year2038.m4 b/m4/year2038.m4
index b9adc99bd..ccc905c91 100644
--- a/m4/year2038.m4
+++ b/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 2
+# year2038.m4 serial 3
 dnl Copyright (C) 2017 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -20,9 +20,12 @@ AC_DEFUN([gl_YEAR2038_EARLY],
 
 AC_DEFUN([gl_YEAR2038],
 [
-  AC_REQUIRE([AC_CANONICAL_HOST])
-  case "$host_os" in
-    mingw*)
+      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 on Linux/x86, this
+      dnl is work in progress; see
+      dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
+      dnl
       dnl On native Windows, the system include files define types __time32_t
       dnl and __time64_t. By default, time_t is an alias of
       dnl   - __time32_t on 32-bit mingw,
@@ -41,8 +44,6 @@ AC_DEFUN([gl_YEAR2038],
            [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
         ])
       if test $gl_cv_type_time_t_64 = no; then
-        dnl Just bail out if 'time_t' is not 64-bit, and let the user fix the
-        dnl problem.
         AC_COMPILE_IFELSE(
           [AC_LANG_SOURCE(
              [[#ifdef _USE_32BIT_TIME_T
@@ -52,15 +53,18 @@ AC_DEFUN([gl_YEAR2038],
                #endif
              ]])],
           [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
-          [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Your system include files surely provide a way to make 'time_t' an alias of '__time64_t'.])])
+          [# If TIME_T_32_BIT_OK is "no" (the default) and not cross-compiling
+           # 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 test "${TIME_T_32_BIT_OK-no}" = no &&
+              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'.])
+           else
+             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"'?])
+           fi])
       fi
-      ;;
-    *)
-      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 on Linux/x86, this
-      dnl is work in progress; see
-      dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
-      ;;
-  esac
 ])
-- 
2.13.6