4 ms·

That's just a software issue. OpenBSD has been using 64-bit time_t on all their architectures for almost a decade now: https://marc.info/?l=openbsd-cvs&m=13763

by ginko 5y ago

That's just a software issue. OpenBSD has been using 64-bit time_t on all their architectures for almost a decade now: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2

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 ago
  Linux 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 ago
    I 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 ago
      Ah 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.
OJFord 5y ago
Yes which is why GP said at the top-level comment you initially replied to: > unless OpenWRT and other distros end up fixing that issue.

by ginko 5y ago

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 ago
Linux 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 ago
  I 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 ago
    Ah 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.

OJFord 5y ago

Yes which is why GP said at the top-level comment you initially replied to: > unless OpenWRT and other distros end up fixing that issue.