Michał Górny (he/they) ∞🙀🚂🐧 on Nostr: New on blog: "The perils of transition to 64-bit #time_t" """ In the "Overview of ...
New on blog: "The perils of transition to 64-bit #time_t"
"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.
There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.
Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""
https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/
"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.
There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.
Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""
https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/