👉 Neuer Blog: „time_t Cast Away: Bits über Bord und der Y2K38 Bug ist zurück“

Die Umstellung auf 64-Bit-time_t gilt als Lösung für das Year 2038 Problem. Doch Direct Casts machen den Fix schnell unwirksam – und schicken uns zurück ins Jahr 1901.

Auf das Wortspiel bin ich ein bisschen stolz ☺️

🔗 https://y2k38.ch/time-t-cast-y2k38-bug/

#Y2K38 #time_t #CProgramming #Year2038Problem #Y2038 #2038Problem #CastAway

https://blog.gslin.org/archives/2025/07/30/12538/debian-%e9%a0%90%e5%ae%9a%e5%9c%a8-13-%e7%89%88-trixie-%e5%85%a8%e9%9d%a2%e5%b0%87-time_t-%e5%be%9e-32-bit-integer-%e6%8f%9b%e7%82%ba-64-bit-integer/

Debian 預定在 13 版 (trixie) 全面將 time_t 從 32-bit integer 換為 64-bit integer

#32Bit #64Bit #debian #epoch #integer #time_t #timestamp #unix

[Перевод] Риски перехода на 64-битный time_t

Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос. Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд. К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.

https://habr.com/ru/articles/847744/

#time_t #unix_time #время #gentoo #дистрибутивы_linux

It looks like my joy in testing #Gentoo #time64 migration was premature.

In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.

Well, I guess we can't do much about that…

#32bit #time_t #y2k38

Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.

Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.

No cóż, z tym wiele nie zrobimy…

#32bit #time_t #y2k38

Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:

• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)

Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.

#y2k38 #32bit #time_t

Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:

• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)

The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.

#y2k38 #32bit #time_t

Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.

Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.

Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.

Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.

#32bit #time_t #y2k38

The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.

Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.

Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.

A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.

#32bit #time_t #y2k38