From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 106A71F8C6 for ; Tue, 6 Jul 2021 22:29:50 +0000 (UTC) Received: from localhost ([::1]:53032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0tZc-0007n1-QS for normalperson@yhbt.net; Tue, 06 Jul 2021 18:29:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0tZY-0007md-TE for bug-gnulib@gnu.org; Tue, 06 Jul 2021 18:29:44 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40252) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0tZV-0001Gp-LE for bug-gnulib@gnu.org; Tue, 06 Jul 2021 18:29:44 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F2C8D160064; Tue, 6 Jul 2021 15:29:38 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CMiqpj_AjwhS; Tue, 6 Jul 2021 15:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 118221600B7; Tue, 6 Jul 2021 15:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z4TK5ZWHUUNm; Tue, 6 Jul 2021 15:29:36 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D6B69160064; Tue, 6 Jul 2021 15:29:36 -0700 (PDT) To: Bruno Haible References: <20210702023332.2482490-1-eggert@cs.ucla.edu> <87y2akltl7.fsf@oldenburg.str.redhat.com> <80b0b2e9-fe2d-f11d-7644-058220394237@cs.ucla.edu> <3476521.qdJYWE5AFN@omega> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64 Message-ID: Date: Tue, 6 Jul 2021 15:29:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3476521.qdJYWE5AFN@omega> Content-Type: multipart/mixed; boundary="------------3E552930ACF19F6A2D496CD0" Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" This is a multi-part message in MIME format. --------------3E552930ACF19F6A2D496CD0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/5/21 6:34 PM, Bruno Haible wrote: > What are these appropriate flags? It was "./configure TIME_T_32_BIT_OK=3Dyes". Though this wasn't documente= d=20 well and perhaps needed other options, and it's different in style from=20 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' -> 'year= 2038', > - how to best document these things. It shouldn't be a module dependency, since year2038 means "I must have=20 64-bit time_t or I won't build" whereas largefile merely means "I want=20 the widest off_t/dev_t/ino_t/time_t available". That being said,=20 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=20 suggestions. The first one is just a doc fix; the second one does the=20 real work. --------------3E552930ACF19F6A2D496CD0 Content-Type: text/x-patch; charset=UTF-8; name="0001-doc-clarify-which-module-fixes-32-bit-time_t.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-doc-clarify-which-module-fixes-32-bit-time_t.patch" =46rom 8d8007df5e302f7f74faefc0f87983adbbc1c8c8 Mon Sep 17 00:00:00 2001 From: Paul Eggert 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 + + 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 =20 year2038: support glibc 2.34 _TIME_BITS=3D64 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 =3D=3D 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 =20 +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 =3D=3D 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 --=20 2.30.2 --------------3E552930ACF19F6A2D496CD0 Content-Type: text/x-patch; charset=UTF-8; name="0002-year2038-Add-disable-year2038-option.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-year2038-Add-disable-year2038-option.patch" =46rom 12169c73bc0008553e6786cd8ef39ccf28cc1519 Mon Sep 17 00:00:00 2001 From: Paul Eggert 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=3DUTF-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 =E2=80=98./configure --disable-year2038=E2=80=99 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 =20 + 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 =E2=80=98./configure + --disable-year2038=E2=80=99 to disable 64-bit time_t when that is not t= he + 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 th= at use a 32-bit @samp{time_t} type. See @url{https://en.wikipedia.org/wiki/Year_2038_pr= oblem} for details. =20 -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" !=3D 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 =20 # 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" !=3D 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 Li= nux, @@ -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 th= e # problem. Otherwise, just warn the builder. - if $1 \ - && test $cross_compiling =3D no \ - && TZ=3DUTC0 touch -t 210602070628.16 conftest.time 2>/dev/nul= l; then - rm -f conftest.time - AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, w= hich your system appears to support. You might try configuring with 'CPPF= LAGS=3D"-m64" LDFLAGS=3D"-m64"'. To build with a 32-bit time_t anyway (no= t recommended), configure with 'TIME_T_32_BIT_OK=3Dyes'.]) - elif test "$gl_warned_about_64_bit_time_t" !=3D yes; then + m4_ifval([$1], + [if test $cross_compiling =3D no \ + && TZ=3DUTC0 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 'C= PPFLAGS=3D"-m64" LDFLAGS=3D"-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" !=3D yes; then AC_MSG_WARN([This package requires a 64-bit 'time_t' type if th= ere is any way to access timestamps outside the year range 1901-2038 on y= our platform. Perhaps you should configure with 'CPPFLAGS=3D"-m64" LDFLAG= S=3D"-m64"'?]) gl_warned_about_64_bit_time_t=3Dyes fi ]) - fi + fi]) ]) =20 AC_DEFUN([gl_YEAR2038], [ - gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" =3D no]) + gl_YEAR2038_BODY([require-64-bit]) ]) --=20 2.30.2 --------------3E552930ACF19F6A2D496CD0--