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/
Jesus Michał "Le Sigh" 🏔 (he)
npub1r9…t4ppx
2024-09-28 15:46:49 UTC
Author Public Key
npub1r9jmk6t0ape7t9ddfv5nrrsh87pluzxtepzjqu93sctkkurun0wqft4ppxPublished at
2024-09-28 15:46:49 UTCEvent JSON
{
"id": "1426afba70567589a698fe45080034523ede893af656ed929a8021c00b7a0ea9",
"pubkey": "1965bb696fe873e595ad4b29318e173f83fe08cbc8452070b186176b707c9bdc",
"created_at": 1727538409,
"kind": 1,
"tags": [
[
"t",
"time_t"
],
[
"t",
"gentoo"
],
[
"proxy",
"https://social.treehouse.systems/users/mgorny/statuses/113215957182674332",
"activitypub"
]
],
"content": "New on blog: \"The perils of transition to 64-bit #time_t\"\n\n\"\"\"\nIn 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.\n\nThere 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.\n\nUnfortunately, 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.\n\"\"\"\n\nhttps://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/",
"sig": "059b06c6cb93eeb8b9ae3abd0dd0a5ebb03c6c288751ce9a747742fa03495dfbc45cc76805b846290779160eb674ae14e2657c0fc73440e519171303455de239"
}