| Keep providing legacy Y2038-incompatible 32-bit time support to 32-bit
Why? OpenBSD did not need to do this and all 3rd party code in the ports tree was fixed upstream. Let’s move to 64 bit time_t and be done with it.
Isn’t it bizarre that the GNU project values binary compat to legacy binaries beyond 2038 this much? Why do they care? The FOSS ecosystem can be recompiled and fixed before it is too late. Vendors will fix their proprietary stuff themselves if they are not given another option.
The argument I’ve seen elsewhere (no real opinion on it myself) is that if you’re still using a 32-bit OS into the future, it gets increasingly likely as time goes on that it’s for some legacy reason, so the pragmatic thing to do is properly fix it in 64-bit code (already done) but only sort of fix it with a backwards compatible kludge in 32-bit code. Then if you can recompile, you either recompile in 64-bit and problem solved, or if you really still need 32-bit for some kind of embedded reason, you port to explicitly use the Y2038-safe API.
Of course, this halfway approach has led to any number of bugs where two sides of an interface have differing ideas about type sizes. Just last year, glibc had 64 bit file offset bugs in some platforms.
Sure, it’s possible. My understanding of the design argument (which I don’t necessarily endorse) is that ABI convention (or other legacy assumptions about the time_t size) is almost the only remaining use-case for a 32-bit OS running unported software. If you can recompile, you’ll either be moving to a 64-bit OS, or consciously using 32-bit due to some specific design tradeoffs, in which case you’ll explicitly use the Y2038-safe API. So that leaves only people running old 32-bit software as-is, which falls in the “legacy” category and will continue to be supported as-is.
Yeah. Hopefully, by 2038 such legacy will run in emulators and a wrong clock and for historical interest only. Much like DOS games can be run in dosbox today.
| Keep providing legacy Y2038-incompatible 32-bit time support to 32-bit
Why? OpenBSD did not need to do this and all 3rd party code in the ports tree was fixed upstream. Let’s move to 64 bit time_t and be done with it.
Isn’t it bizarre that the GNU project values binary compat to legacy binaries beyond 2038 this much? Why do they care? The FOSS ecosystem can be recompiled and fixed before it is too late. Vendors will fix their proprietary stuff themselves if they are not given another option.
The argument I’ve seen elsewhere (no real opinion on it myself) is that if you’re still using a 32-bit OS into the future, it gets increasingly likely as time goes on that it’s for some legacy reason, so the pragmatic thing to do is properly fix it in 64-bit code (already done) but only sort of fix it with a backwards compatible kludge in 32-bit code. Then if you can recompile, you either recompile in 64-bit and problem solved, or if you really still need 32-bit for some kind of embedded reason, you port to explicitly use the Y2038-safe API.
Of course, this halfway approach has led to any number of bugs where two sides of an interface have differing ideas about type sizes. Just last year, glibc had 64 bit file offset bugs in some platforms.
| still using a 32-bit OS into the future
64 bit timet is just an ABI convention issue. Using 32 bit OS and CPU does not prevent use of 64 bit timet (see OpenBSD/i386 for example).
Sure, it’s possible. My understanding of the design argument (which I don’t necessarily endorse) is that ABI convention (or other legacy assumptions about the time_t size) is almost the only remaining use-case for a 32-bit OS running unported software. If you can recompile, you’ll either be moving to a 64-bit OS, or consciously using 32-bit due to some specific design tradeoffs, in which case you’ll explicitly use the Y2038-safe API. So that leaves only people running old 32-bit software as-is, which falls in the “legacy” category and will continue to be supported as-is.
Yeah. Hopefully, by 2038 such legacy will run in emulators and a wrong clock and for historical interest only. Much like DOS games can be run in dosbox today.
Perhaps it’s time for a libc7….