3 ms·
It's worth noting that this was possible because OpenBSD are happy to break their ABI in order to improve their operating system. Linux values ABI stability hig
by yrro 5y ago
It's worth noting that this was possible because OpenBSD are happy to break their ABI in order to improve their operating system. Linux values ABI stability highly, and prefers to introduce new interfaces that applications have to opt into (e.g., as was done with support for 64-bit file offsets on 32-bit architectures).
- Deukhoofd 5y agoLinux 5.6+ made time_t 64 bit in kernelspace. musl 1.2+ and glibc 2.32+ made it 64 bit in userspace as well.
- yrro 5y agoI think you mean glibc 2.34: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html https://sourceware.org/pipermail/libc-alpha/2021-August/1297... You opt-in by building with -D_TIME_BITS=64: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fTIME_005fBITS https://www.gnu.org/software/libc/manual/html_node/Feature-T... An approach not without its problems: https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/ https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-co... - but then again software that relies on time_t being 32 bits has been broken on 64-bit architectures for a very long time already, surely? I suppose I could have written that "GNU/Linux values ABI stability" in my comment, instead of plain "Linux"... ;)
- Deukhoofd 5y agoAh yes you're right, I was going by the Linux 5.6 release notes, which gave 2.32 as version. I personally fully expect TIME_BITS to default to 64 soon, but looking at the 2.35 fixed bugs, they were right in not immediately switching it over. I see at least 2 bugs related to it.