64-bit time_t

64-bit time_t

[Bernhard M. Wiedemann]

[-- Attachment #1.1: Type: text/plain, Size: 1529 bytes --]

In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
Bruno Haible wrote:

> Regarding the distro people:
> 
>   The outcome of a discussion, about a month or two ago, was AFAIU that
>   Linux/x86 and Linux/arm distros have a choice between
>     (a) enabling 64-bit time_t for all packages, thus breaking ABI
>         compatibility once and becoming year 2038 saft, or
>     (b) staying with the 32-bit time_t, and announcing that their
>         distro will stop working in 2038.
>   An incremental or partial move to 64-bit time_t would be too expensive,
>   did the distro people say.

or option c)
One less troublesome solution could be to patch glibc to redefine the 
32-bit time_t as unsigned so that ABIs could remain compatible and at 
the same time it would support timestamps until 2106.
Though that would break any application that uses time_t for dates 
between 1901 and 1970 (are there any?).
Do I miss any other downsides?
This seems to be the only option that allows legacy-binaries to keep 
working after 2038.


option d) would be to adapt all libraries that have time_t in their API 
to have both 32-bit and 64-bit time_t variants. The former for 
compatibility with old binaries and the latter for new future-proof 
binaries. This could provide a smooth transition because not all 
3rd-party binaries can be rebuilt.
The trouble here would be the effort for the libraries to provide 2 
variants and for callers to select the right variant.


Ciao
Bernhard M.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: 64-bit time_t

[Neal Gompa]

On Tue, Jan 2, 2024 at 7:45 AM Bernhard M. Wiedemann <bwiedemann@suse.de> wrote:
>
> In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
> Bruno Haible wrote:
>
> > Regarding the distro people:
> >
> >   The outcome of a discussion, about a month or two ago, was AFAIU that
> >   Linux/x86 and Linux/arm distros have a choice between
> >     (a) enabling 64-bit time_t for all packages, thus breaking ABI
> >         compatibility once and becoming year 2038 saft, or
> >     (b) staying with the 32-bit time_t, and announcing that their
> >         distro will stop working in 2038.
> >   An incremental or partial move to 64-bit time_t would be too expensive,
> >   did the distro people say.
>
> or option c)
> One less troublesome solution could be to patch glibc to redefine the
> 32-bit time_t as unsigned so that ABIs could remain compatible and at
> the same time it would support timestamps until 2106.
> Though that would break any application that uses time_t for dates
> between 1901 and 1970 (are there any?).
> Do I miss any other downsides?
> This seems to be the only option that allows legacy-binaries to keep
> working after 2038.
>
>
> option d) would be to adapt all libraries that have time_t in their API
> to have both 32-bit and 64-bit time_t variants. The former for
> compatibility with old binaries and the latter for new future-proof
> binaries. This could provide a smooth transition because not all
> 3rd-party binaries can be rebuilt.
> The trouble here would be the effort for the libraries to provide 2
> variants and for callers to select the right variant.
>

In my view, Option D would be ideal, but otherwise we should probably
just break everything and do option A unless glibc has already
switched unsigned numbers for time_t in 64-bit time, so then using
32-bit time_t unsigned would be "okay" and thus Option C would work.




--
真実はいつも一つ！/ Always, there's only one truth!

Re: 64-bit time_t

[Adrien Nader]

Hi,

On Tue, Jan 02, 2024, Bernhard M. Wiedemann wrote:
> In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
> Bruno Haible wrote:
> 
> > Regarding the distro people:
> > 
> >   The outcome of a discussion, about a month or two ago, was AFAIU that
> >   Linux/x86 and Linux/arm distros have a choice between
> >     (a) enabling 64-bit time_t for all packages, thus breaking ABI
> >         compatibility once and becoming year 2038 saft, or
> >     (b) staying with the 32-bit time_t, and announcing that their
> >         distro will stop working in 2038.
> >   An incremental or partial move to 64-bit time_t would be too expensive,
> >   did the distro people say.
> 
> or option c)
> One less troublesome solution could be to patch glibc to redefine the 32-bit
> time_t as unsigned so that ABIs could remain compatible and at the same time
> it would support timestamps until 2106.
> Though that would break any application that uses time_t for dates between
> 1901 and 1970 (are there any?).
> Do I miss any other downsides?
> This seems to be the only option that allows legacy-binaries to keep working
> after 2038.
> 
> 
> option d) would be to adapt all libraries that have time_t in their API to
> have both 32-bit and 64-bit time_t variants. The former for compatibility
> with old binaries and the latter for new future-proof binaries. This could
> provide a smooth transition because not all 3rd-party binaries can be
> rebuilt.
> The trouble here would be the effort for the libraries to provide 2 variants
> and for callers to select the right variant.

There is a major issue there and that probably applies to option c) too,
albeit in a different form: we don't know which packages are relevant.

We cannot tell which packages use dates before 1970 since everyone is
free to run "date -d @-1".

And we cannot tell which packages' ABI is influenced by time_t. We could
grep APIs for "time_t" but that's not enough since the type is embedded
in other types and what matters in the end is the ABI.

For Ubuntu, we've been building headers with both 32-bit and 64-bit
time_t in order to compare their ABIs with abi-compliance-checker. It's
been tiresome and it's not complete but at least it shows which
packages' ABI remain the same. This approach is not perfect but it might
be the best at scale.
Out of more than 5200 source packages in Debian unstable mid-December,
roughly 3000 ABIs don't change, more than 600 do and 1100 I couldn't
tell (and then there are some changes due to LFS).

Doing these headers rebuild has taken a lot of time so far because there
are many build failures for a lot of different reasons. It's possible
that you could get something more easily with libabigail (possibly with
abi-compliance-checker's current approach to ABI dumps) but that means
building everything in a different way and it's not guaranteed you get
less failures that way or that results that make sense when looking at
one package also make sense when looking at all a distro's packages.

Also, thinking about it just now: if it's possible to walk up the type
hierarchy through e.g. libabigail, it should be possible to find out
programmatically which types depend on time_t and friends. It might be
interesting to try that as we could then compare that to the results we
have so far.  I'm sure some software changes type definition based on
the size of time_t through preprocessor tests but I can't tell how many
(but maybe we'll find out by comparing results).

-- 
Adrien

Re: 64-bit time_t

[Andreas K. Huettel]

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

> In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
> Bruno Haible wrote:
> 
> > Regarding the distro people:
> > 
> >   The outcome of a discussion, about a month or two ago, was AFAIU that
> >   Linux/x86 and Linux/arm distros have a choice between
> >     (a) enabling 64-bit time_t for all packages, thus breaking ABI
> >         compatibility once and becoming year 2038 saft, or

CHOST=i686-pc-linux-gnut64

> >     (b) staying with the 32-bit time_t, and announcing that their
> >         distro will stop working in 2038.

CHOST=i686-pc-linux-gnu

> >   An incremental or partial move to 64-bit time_t would be too expensive,
> >   did the distro people say.

That's the option "pain without end" (instead of an end with pain).

> or option c)
> One less troublesome solution could be to patch glibc to redefine the 
> 32-bit time_t as unsigned so that ABIs could remain compatible and at 
> the same time it would support timestamps until 2106.
> Though that would break any application that uses time_t for dates 
> between 1901 and 1970 (are there any?).
> Do I miss any other downsides?

ENOCRYSTALBALL - how do you find where it's needed and where not?
it was perfectly legal so far...

> option d) would be to adapt all libraries that have time_t in their API 
> to have both 32-bit and 64-bit time_t variants. The former for 
> compatibility with old binaries and the latter for new future-proof 
> binaries. This could provide a smooth transition because not all 
> 3rd-party binaries can be rebuilt.

But please please please no ugly fiddling with soname.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]