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.