Re: year 2038 is only 12 years away

Michał Górny <[email protected]> Sun, 18 Jan 2026 04:18:20 +0100
Newsgroups dev.linux.lists.distributions
Organization Gentoo
Message-ID <[email protected]>
--=-urdaYAK4fIcPsXH7GS3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2026-01-18 at 03:28 +0100, Bernhard M. Wiedemann wrote:
> I think, some distributions already started to compile their 32-bit code=
=20
> with `-D_TIME_BITS=3D64 -D_FILE_OFFSET_BITS=3D64` but that is only part o=
f=20
> the solution.
> Code that handles timestamps regularly gets added or rewritten and every=
=20
> time, developers need to remember to not use `int` there (nor `long` on=
=20
> 32-bit systems) but `long long` or `int64_t` or just `time_t`. I myself=
=20
> sent PRs in the past using `atol` for timestamps. We should not do that=
=20
> anymore. same for `scanf("%l")`.
>=20
> I opened a discussion with the gcc devs at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D118326 about adding=20
> warnings for int=3D>time_t conversions. It did not yet get very far, but=
=20
> at least a collegue at SUSE made a PoC patch and identified some corner=
=20
> cases.
>=20

Thanks for working on this.  Personally, I think the biggest problem is
that a lot of people don't test their software on 32-bit platforms at
all.  And the primary cause of that problem is that a large number of
popular CI platforms don't provide 32-bit environments at all (and
people obviously don't go out of their way to, say, run a 32-bit
container on top of the 64-bit CI environment).

--=20
Best regards,
Micha=C5=82 G=C3=B3rny


--=-urdaYAK4fIcPsXH7GS3f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iKQEABYKAEwWIQQcFD0bEK7NPNmWHtiOMjR69AVa6AUCaWxQ/BsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDISHG1nb3JueUBnZW50b28ub3JnAAoJEI4yNHr0BVro
9fQA/0KgvS3Sz5p8FN0ZsZR1G3qv0KwbLZdEE35lTABrky6wAPwOMVhuBFcHLpky
YbjCHB9WEIHjNciG2uoIEiUtAsQtCg==
=HLk2
-----END PGP SIGNATURE-----

--=-urdaYAK4fIcPsXH7GS3f--