public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Elmar Stellnberger <estellnb@elstel.org>,
	libc-alpha@sourceware.org, libc-maintainers@gnu.org
Subject: Re: time64 functions for glibc
Date: Mon, 31 May 2021 11:46:09 -0700	[thread overview]
Message-ID: <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> (raw)
In-Reply-To: <fa203fc7-15f6-c358-3950-da1361d391e1@linaro.org>

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

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 LFS,
> you will need a newer flag to actually enable it (-D_TIME_BITS=64).

One place where Microsoft got it right and we're arguably getting it 
wrong, is that 64-bit time_t is the default on 32-bit MS-Windows, where 
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 
at least document that 64-bit time_t is planned to be default in the 
future. That is, programmers should not *rely* on 32-bit being the default.

Obviously 64-bit will have to be the default eventually. (Rumors of x86 
dying out completely before 2038 are exaggerated; some 32-bit software 
will likely live on past 2038 even if 32-bit-only chips are no longer 
made.) We should warn developers about that now.

Since making 64-bit time_t the default also means 64-bit off_t will be 
the default, we should warn developers about that too.

Proposed patch attached, relative to the azanella/y2038 branch.

[-- Attachment #2: 0001-doc-_TIME_BITS-defaults-may-change.patch --]
[-- Type: text/x-patch, Size: 5469 bytes --]

From c2d79754d2ddd706142e643cef29021167c053f7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
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:
 
 * The ISO C2X function timespec_getres has been added.
 
-* 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 unchanged.
   This is enabled with the _TIME_BITS preprocessor set to 64 and only
   supported when LFS (_FILE_OFFSET_BITS=64) is also enabled.  It is only
   enabled for Linux and the full support requires a minimum version of 5.1.
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.
 
-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.
 
@@ -157,6 +157,11 @@ under different names (as they are with @code{_LARGEFILE64_SOURCE}).
 Instead the old function names now reference the new functions, e.g., a
 call to @code{fseeko} now indeed calls @code{fseeko64}.
 
+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
 
 @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.
 
-Possible values of @code{_TIME_BITS}:
 @enumerate
-@item
-@code{_TIME_BITS=64} 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
 
 @item
-@code{_TIME_BITS=32} 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.
 
 @item
-@code{_TIME_BITS=64} 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. Otherwise,
+a fallback code is used with legacy (i.e. 32-bit) syscalls.
 
 @item
-@code{_TIME_BITS=64} 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.
 
 @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
 
-The @code{_TIME_BITS} can be only used when @code{_FILE_OFFSET_BITS=64}
-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. Otherwise,
-a fallback code is used with legacy (i.e. 32-bit) syscalls.
+@code{_TIME_BITS=64} can be defined only when
+@code{_FILE_OFFSET_BITS=64} is also defined.
 
 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
 
 @defvr Macro _ISOC99_SOURCE
-- 
2.27.0


  reply	other threads:[~2021-05-31 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31 15:43 Elmar Stellnberger
2021-05-31 15:51 ` Paul Zimmermann
2021-05-31 16:01 ` Adhemerval Zanella
2021-05-31 18:46   ` Paul Eggert [this message]
2021-05-31 18:56     ` Florian Weimer
2021-05-31 19:08       ` Adhemerval Zanella
2021-05-31 19:16         ` Florian Weimer
2021-05-31 19:28           ` Adhemerval Zanella
2021-06-01 16:32             ` Elmar Stellnberger
2021-05-31 19:03     ` Adhemerval Zanella
2021-06-22 21:41       ` Paul Eggert
2021-06-23 13:29         ` Adhemerval Zanella
2021-06-23 16:59         ` Joseph Myers
2021-06-23 17:59           ` Paul Eggert
2021-06-24 17:37             ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=adhemerval.zanella@linaro.org \
    --cc=estellnb@elstel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-maintainers@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).