time64 functions for glibc

time64 functions for glibc

[Elmar Stellnberger]

Dear maintainers of the glibc

   The year 2038 is coming soon and I still have many 32bit programs in 
use. There has been a draft to make glibc time64_t fit:
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

   Unfortunately this has not been implemented all the years since the 
time has become 64bit in the kernel. Under Windows time64_t is available 
since long. Can you please tell me when you are planning to work on 
this? - I am currently programming https://www.elstel.org/atea/ and of 
course I would have liked to make the program time64_t fit without 
having to access kernel sources and without having to implement 
time64_t2char* conversion myself. The time implementation of libopenssl 
is also 32bit but it has a wraparound so that proper ASN-time usage will 
be possible after 2038. - And what about all the 32bit SoC computers 
like the Raspberry Pi? They also run Linux!!

Yours Sincerely,
Elmar Stellnberger

P.S.: Please acknowledge the receival of this email before you answer.

Re: time64 functions for glibc

[Paul Zimmermann]

       Dear Elmar,

> P.S.: Please acknowledge the receival of this email before you answer.

your mail has been received:

https://sourceware.org/pipermail/libc-alpha/2021-May/126966.html

Best regards,
Paul Zimmermann

Re: time64 functions for glibc

[Adhemerval Zanella]

On 31/05/2021 12:43, Elmar Stellnberger via Libc-alpha wrote:
> Dear maintainers of the glibc
> 
>   The year 2038 is coming soon and I still have many 32bit programs in use. There has been a draft to make glibc time64_t fit:
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
> 
>   Unfortunately this has not been implemented all the years since the time has become 64bit in the kernel. Under Windows time64_t is available since long. Can you please tell me when you are planning to work on this? - I am currently programming https://www.elstel.org/atea/ and of course I would have liked to make the program time64_t fit without having to access kernel sources and without having to implement time64_t2char* conversion myself. The time implementation of libopenssl is also 32bit but it has a wraparound so that proper ASN-time usage will be possible after 2038. - And what about all the 32bit SoC computers like the Raspberry Pi? They also run Linux!!
> 
> Yours Sincerely,
> Elmar Stellnberger
> 
> P.S.: Please acknowledge the receival of this email before you answer.

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). 

The intended work for 2.34 still misses some ABI (utmp, utmpx, and lastlogin)
and installed programs would still use 32-bit; but it should enable
programs to proper support 64-bit.

[1] https://patchwork.sourceware.org/project/glibc/list/?series=2199

Re: time64 functions for glibc

[Paul Eggert]

[-- 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

Re: time64 functions for glibc

[Florian Weimer]

* Paul Eggert:

> 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.

I strongly object to that for i386-linux-gnu.  It's pretty much for
compatibility with legacy applications at this point, and changing the
default will only make it harder for distributions to support legacy
use.  Software that can be recompiled (and thus switch to 64-bit time_t)
really should be ported to a 64-bit architecture.

I don't have an opinion about what people to do with 32-bit Arm.

Thanks,
Florian

Re: time64 functions for glibc

[Adhemerval Zanella]

On 31/05/2021 15:46, Paul Eggert wrote:
> 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.

Yes, this is BZ#13047 [1] and BZ#14106 [2]. The BZ#14106 would
require to move the current LFS to compat symbols and add
newer double underscore ones for the affected architectures
(and it is really messy that LFS supported for architecture
with current 64 off_t support added alias symbols).

But I think we should move to make LFS and 64 bit time_t default
even without BZ#14106 fixed, maybe this is still time for 2.34.
In any case, my plan is to fix on 2.35.

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

Thanks, the patch looks reasonable and I will add merge on the
patch that enable the y2038 symbols.  

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13047
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=14106

Re: time64 functions for glibc

[Adhemerval Zanella]

On 31/05/2021 15:56, Florian Weimer wrote:
> * Paul Eggert:
> 
>> 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.
> 
> I strongly object to that for i386-linux-gnu.  It's pretty much for
> compatibility with legacy applications at this point, and changing the
> default will only make it harder for distributions to support legacy
> use.  Software that can be recompiled (and thus switch to 64-bit time_t)
> really should be ported to a 64-bit architecture.

We either make it default for all affected architectures or we should
keep as is, I see not point in making it architecture dependent.

And I don't see your point here: if the legacy is being recompiled
it is in essence not in compatibility mode.  We really need to move
from non-LFS and 32-bit time_t interfaces.

> 
> I don't have an opinion about what people to do with 32-bit Arm.
> 
> Thanks,
> Florian
> 

Re: time64 functions for glibc

[Florian Weimer]

* Adhemerval Zanella:

> We either make it default for all affected architectures or we should
> keep as is, I see not point in making it architecture dependent.

I'm under the impression that 32-bit Arm is sufficiently different.

> And I don't see your point here: if the legacy is being recompiled
> it is in essence not in compatibility mode.  We really need to move
> from non-LFS and 32-bit time_t interfaces.

It's about providing a stack of 32-bit libraries for use by legacy
applications.  These libraries are rebuilt from time to time by
distributions and would pick up the changed default, therefore becoming
incompatible with legacy applications.  Development work is required to
support both ABIs in one installation.  If no one is willing to do the
work (which is what I expect for most of the relevant libraries), for
i386 the more useful choice is the current ABI, to support legacy
applications that can't be recompiled.

Thanks,
Florian

Re: time64 functions for glibc

[Adhemerval Zanella]

On 31/05/2021 16:16, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> We either make it default for all affected architectures or we should
>> keep as is, I see not point in making it architecture dependent.
> 
> I'm under the impression that 32-bit Arm is sufficiently different.

It might make sense on how a distribution is build and deployed, but I
think from glibc point is view regarding LFS and 64 bit time_t support
they should be handled the same.

> 
>> And I don't see your point here: if the legacy is being recompiled
>> it is in essence not in compatibility mode.  We really need to move
>> from non-LFS and 32-bit time_t interfaces.
> 
> It's about providing a stack of 32-bit libraries for use by legacy
> applications.  These libraries are rebuilt from time to time by
> distributions and would pick up the changed default, therefore becoming
> incompatible with legacy applications.  Development work is required to
> support both ABIs in one installation.  If no one is willing to do the
> work (which is what I expect for most of the relevant libraries), for
> i386 the more useful choice is the current ABI, to support legacy
> applications that can't be recompiled.

I don't have a good answer for case where the libraries uses time_t
and related types on their own ABI, it would indeed require some
work.  But at same time if they are bounded by this, these very
libraries and application will most likely run in trouble eventually 
due y2038.

I already heard some issue regarding LFS support in the wild, autoconf 
and other configuration system tries hard to make is default but even
then there are cases where they are not used (the BZ#23960 for instance).

So I still think making *better* defaults, even if it requires some work
from consumers, is better than keep ABIs with either underlying issues or
inherent faulty support.

Re: time64 functions for glibc

[Elmar Stellnberger]

Yes, I think a 64bit default for time_t shall at least become the way of choice some time before 2038. AFAIK OpenBSD already has a 64bit time_t in kernel and libc. I don't know of a program that did not compile or that was put out of function because of it though it may not extend to the majority of sw in ports. I will have to test and install BSD to see whether it is like this. BSD has its own libc and libssl. Libraries like openssl will likely require some adaption for the switch. For the transition period where time is 32bit in Linux based openssl I can f.i. convert from 64bit time to struct tm and then to openssl datetime.

Am 31. Mai 2021 21:28:14 MESZ schrieb Adhemerval Zanella <adhemerval.zanella@linaro.org>:
>
>
>On 31/05/2021 16:16, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> We either make it default for all affected architectures or we
>should
>>> keep as is, I see not point in making it architecture dependent.
>> 
>> I'm under the impression that 32-bit Arm is sufficiently different.
>
>It might make sense on how a distribution is build and deployed, but I
>think from glibc point is view regarding LFS and 64 bit time_t support
>they should be handled the same.
>
>> 
>>> And I don't see your point here: if the legacy is being recompiled
>>> it is in essence not in compatibility mode.  We really need to move
>>> from non-LFS and 32-bit time_t interfaces.
>> 
>> It's about providing a stack of 32-bit libraries for use by legacy
>> applications.  These libraries are rebuilt from time to time by
>> distributions and would pick up the changed default, therefore
>becoming
>> incompatible with legacy applications.  Development work is required
>to
>> support both ABIs in one installation.  If no one is willing to do
>the
>> work (which is what I expect for most of the relevant libraries), for
>> i386 the more useful choice is the current ABI, to support legacy
>> applications that can't be recompiled.
>
>I don't have a good answer for case where the libraries uses time_t
>and related types on their own ABI, it would indeed require some
>work.  But at same time if they are bounded by this, these very
>libraries and application will most likely run in trouble eventually 
>due y2038.
>
>I already heard some issue regarding LFS support in the wild, autoconf 
>and other configuration system tries hard to make is default but even
>then there are cases where they are not used (the BZ#23960 for
>instance).
>
>So I still think making *better* defaults, even if it requires some
>work
>from consumers, is better than keep ABIs with either underlying issues
>or
>inherent faulty support.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: time64 functions for glibc

[Paul Eggert]

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

On 5/31/21 12:03 PM, Adhemerval Zanella wrote:

>> Proposed patch attached, relative to the azanella/y2038 branch.
> 
> Thanks, the patch looks reasonable and I will add merge on the
> patch that enable the y2038 symbols.

That documentation patch didn't make it into the master branch when the 
corresponding y2038 symbols did. OK to install that doc patch now? I've 
attached it to this email (this is relative to current master).

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

From 9784d7dce26553f40ec49648c337d6c95e95a8af Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 22 Jun 2021 14:36:25 -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 72115073fb..cedc998a22 100644
--- a/NEWS
+++ b/NEWS
@@ -31,7 +31,7 @@ Major new features:
   __STDC_WANT_IEC_60559_BFP_EXT__, as specified in TS 18661-1, is
   defined, and when _GNU_SOURCE is defined.
 
-* 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 9fa658e9a7..d3c4fa4702 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.30.2

Re: time64 functions for glibc

[Adhemerval Zanella]

On 22/06/2021 18:41, Paul Eggert wrote:
> On 5/31/21 12:03 PM, Adhemerval Zanella wrote:
> 
>>> Proposed patch attached, relative to the azanella/y2038 branch.
>>
>> Thanks, the patch looks reasonable and I will add merge on the
>> patch that enable the y2038 symbols.
> 
> That documentation patch didn't make it into the master branch when the corresponding y2038 symbols did. OK to install that doc patch now? I've attached it to this email (this is relative to current master).

LGTM, thanks. Sorry, I missed the rebase to include it.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Re: time64 functions for glibc

[Joseph Myers]

On Tue, 22 Jun 2021, Paul Eggert wrote:

> -* 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.

I think the intended meaning of this was that "ABIs with defaults to 32 
bit time_t" was a phrase describing those glibc configurations for which 
support for 64-bit time_t was added (as opposed to those glibc 
configurations already defaulting to 64-bit time_t in previous glibc 
versions, for which nothing was changed), rather than "defaults to 32 bit 
time_t" being a description of how the new feature behaves.  I.e. this 
change loses the information that many configurations already used 64-bit 
time_t and so were unaffected by this change.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: time64 functions for glibc

[Paul Eggert]

On 6/23/21 9:59 AM, Joseph Myers wrote:
>> -* 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.

> I think the intended meaning of this was that "ABIs with defaults to 32
> bit time_t" was a phrase describing those glibc configurations for which
> support for 64-bit time_t was added

Oh, that intended meaning wasn't clear to me. How about if we change 
that sentence to the following, which I hope makes things clearer.

* Add support for 64-bit time_t on configurations like x86 where time_t
   is traditionally 32-bit.  Although time_t still defaults to 32-bit on
   these configurations, this default may change in future versions.

Re: time64 functions for glibc

[Joseph Myers]

On Wed, 23 Jun 2021, Paul Eggert wrote:

> On 6/23/21 9:59 AM, Joseph Myers wrote:
> > > -* 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.
> 
> > I think the intended meaning of this was that "ABIs with defaults to 32
> > bit time_t" was a phrase describing those glibc configurations for which
> > support for 64-bit time_t was added
> 
> Oh, that intended meaning wasn't clear to me. How about if we change that
> sentence to the following, which I hope makes things clearer.
> 
> * Add support for 64-bit time_t on configurations like x86 where time_t
>   is traditionally 32-bit.  Although time_t still defaults to 32-bit on
>   these configurations, this default may change in future versions.

This wording is OK with me.

-- 
Joseph S. Myers
joseph@codesourcery.com