From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 793693858004 for ; Mon, 31 May 2021 18:46:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 793693858004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eggert@cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8B8191600E9; Mon, 31 May 2021 11:46:11 -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 4na38BKPNQMy; Mon, 31 May 2021 11:46:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 592DD1600FB; Mon, 31 May 2021 11:46:10 -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 xQU6LhvLTl6Q; Mon, 31 May 2021 11:46:10 -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 292111600E9; Mon, 31 May 2021 11:46:10 -0700 (PDT) To: Adhemerval Zanella References: <8bb369a7-ebc0-d108-ca38-0ba2c658df12@elstel.org> From: Paul Eggert Organization: UCLA Computer Science Department Cc: Elmar Stellnberger , libc-alpha@sourceware.org, libc-maintainers@gnu.org Subject: Re: time64 functions for glibc Message-ID: <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> Date: Mon, 31 May 2021 11:46:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------B74109D37256613FD87F2407" Content-Language: en-US X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 18:46:14 -0000 This is a multi-part message in MIME format. --------------B74109D37256613FD87F2407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 5/31/21 9:01 AM, Adhemerval Zanella via Libc-alpha wrote: > It is on 2.34 plan [1], Carlos O'Donnel is reviewing it. Similar to LF= S, > you will need a newer flag to actually enable it (-D_TIME_BITS=3D64). One place where Microsoft got it right and we're arguably getting it=20 wrong, is that 64-bit time_t is the default on 32-bit MS-Windows, where=20 one must opt into 32-bit by #defining _USE_32BIT_TIME_T. It's too late in 2.34 to make 64-bit time_t the default, but we should=20 at least document that 64-bit time_t is planned to be default in the=20 future. That is, programmers should not *rely* on 32-bit being the defaul= t. Obviously 64-bit will have to be the default eventually. (Rumors of x86=20 dying out completely before 2038 are exaggerated; some 32-bit software=20 will likely live on past 2038 even if 32-bit-only chips are no longer=20 made.) We should warn developers about that now. Since making 64-bit time_t the default also means 64-bit off_t will be=20 the default, we should warn developers about that too. Proposed patch attached, relative to the azanella/y2038 branch. --------------B74109D37256613FD87F2407 Content-Type: text/x-patch; charset=UTF-8; name="0001-doc-_TIME_BITS-defaults-may-change.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-doc-_TIME_BITS-defaults-may-change.patch" =46rom c2d79754d2ddd706142e643cef29021167c053f7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 31 May 2021 11:40:49 -0700 Subject: [PATCH] doc: _TIME_BITS defaults may change * NEWS: Don't imply the default will always be 32-bit. * manual/creature.texi (Feature Test Macros): Say that _TIME_BITS and _FILE_OFFSET_BITS defaults may change in future releases. --- NEWS | 2 +- manual/creature.texi | 57 ++++++++++++++++++++++---------------------- 2 files changed, 29 insertions(+), 30 deletions(-) diff --git a/NEWS b/NEWS index 3bb122ec3c..806b6ac2e3 100644 --- a/NEWS +++ b/NEWS @@ -25,7 +25,7 @@ Major new features: =20 * The ISO C2X function timespec_getres has been added. =20 -* Add support for 64 bit time_t for ABIs with defaults to 32 bit time_t.= +* Add support for 64 bit time_t for ABIs with defaults currently unchang= ed. This is enabled with the _TIME_BITS preprocessor set to 64 and only supported when LFS (_FILE_OFFSET_BITS=3D64) is also enabled. It is on= ly enabled for Linux and the full support requires a minimum version of 5= =2E1. diff --git a/manual/creature.texi b/manual/creature.texi index 606b73d184..0ff84ce8fd 100644 --- a/manual/creature.texi +++ b/manual/creature.texi @@ -146,8 +146,8 @@ bit} interface available as an additional interface, @code{_FILE_OFFSET_BITS} allows the @w{64 bit} interface to replace the old interface. =20 -If @code{_FILE_OFFSET_BITS} is undefined, or if it is defined to the -value @code{32}, nothing changes. The @w{32 bit} interface is used and +If @code{_FILE_OFFSET_BITS} is defined to the +value @code{32}, the @w{32 bit} interface is used and types like @code{off_t} have a size of @w{32 bits} on @w{32 bit} systems. =20 @@ -157,6 +157,11 @@ under different names (as they are with @code{_LARGE= FILE64_SOURCE}). Instead the old function names now reference the new functions, e.g., a call to @code{fseeko} now indeed calls @code{fseeko64}. =20 +If the macro is not defined it currently defaults to @code{32}, but +this default is planned to change due to a need to update +@code{time_t} for Y2038 safety, and applications should not rely on +the default. + This macro should only be selected if the system provides mechanisms for= handling large files. On @w{64 bit} systems this macro has no effect since the @code{*64} functions are identical to the normal functions. @@ -166,47 +171,41 @@ This macro was introduced as part of the Large File= Support extension @end defvr =20 @defvr Macro _TIME_BITS -This macro determines the bit size of @code{time_t} (and therefore the -bit size of all @code{time_t} derived types and the prototypes of all -related functions). If @code{_TIME_BITS} is undefined, the bit size of -@code{time_t} is architecture dependent. +This macro determines the bit size of @code{time_t}, and therefore the +bit size of all @code{time_t}-derived types and the prototypes of all +related functions. =20 -Possible values of @code{_TIME_BITS}: @enumerate -@item -@code{_TIME_BITS=3D64} and port from the outset uses 64-bit -@code{time_t} and word size equals to @w{64 bits} (e.g. x86_64) - no -action =20 @item -@code{_TIME_BITS=3D32} and port from the outset uses 32-bit -@code{time_t} and word size equals to @w{64 bits} (e.g. ARM) - no -action +If @code{_TIME_BITS} is undefined, the bit size of @code{time_t} is +architecture dependent. Currently it defaults to 64 bits on most +architectures. Although it defaults to 32 bits on some traditional +architectures (i686, ARM), this is planned to change and applications +should not rely on this. =20 @item -@code{_TIME_BITS=3D64} and port from the outset uses 64-bit -@code{time_t} and word size equals to @w{32 bits} (e.g. ARC, RV32) -- no action +If @code{_TIME_BITS} is defined to be 64, @code{time_t} is defined +to be a 64-bit integer. On platforms where @code{time_t} was +traditionally 32 bits, calls to proper syscalls depend on the +Linux kernel version on which the system is running. For Linux kernel +version above @b{5.1} syscalls supporting 64-bit time are used. Otherwis= e, +a fallback code is used with legacy (i.e. 32-bit) syscalls. =20 @item -@code{_TIME_BITS=3D64} and port from the outset uses 32-bit -@code{time_t} and word size equals to @w{32 bits} (e.g. ARM) -- the @code{time_t} is modified to be able to hold 64-bit time. +If @code{_TIME_BITS} is defined to be 32, @code{time_t} is defined to +be a 32-bit integer where that is supported. This is not recommended, +as 32-bit @code{time_t} stops working in the year 2038. =20 @item -For any other use case the compile-time error is emitted. +For any other use case a compile-time error is emitted. @end enumerate =20 -The @code{_TIME_BITS} can be only used when @code{_FILE_OFFSET_BITS=3D64= } -is also defined. - -For the point @b{4} above, calls to proper syscalls depend on the -Linux kernel version on which the system is running. For Linux kernel -version above @b{5.1} syscalls supporting 64-bit time are used. Otherwis= e, -a fallback code is used with legacy (i.e. 32-bit) syscalls. +@code{_TIME_BITS=3D64} can be defined only when +@code{_FILE_OFFSET_BITS=3D64} is also defined. =20 By using this macro certain ports gain support for 64-bit time and as -a result become immune to Y2038 problem. +a result become immune to the Y2038 problem. @end defvr =20 @defvr Macro _ISOC99_SOURCE --=20 2.27.0 --------------B74109D37256613FD87F2407--