4 ms·
> It should be noted that both approaches described above introduce zero friction to get the right thing. If your code is called by any other code and took in
by tick_tock_tick 5y ago
> It should be noted that both approaches described above introduce zero friction to get the right thing.
If your code is called by any other code and took in a time_t recompiling would have broken your ABI.
- mlyle 5y agoSure. And the ABI needs to break sometime before 2038. So, new major libc version, and... I mean, waiting does mean there will be fewer 32 bit systems: so there's an argument to put off the transition to lower the scope of work. However, most of the ones that stay around will be embedded and long-lived: just the worst kind of thing to bite us in the future.
- mrweasel 5y ago> Sure. And the ABI needs to break sometime before 2038. That really highlights the benefit of the BSD model, where the OS, libc and all the base packages are shipped as a complete system. OpenBSD switch to 64 bit time_t on all supported platforms back in 2014. We all talked about Y2038 back then, and most agreed that something should be now as quickly as possible. Then the world just sort of forgot. I mean it is solved, but if you're a new developer, you might not know that you need to do something special. The GNU and Linux world is really good at not breaking ABI compatibility and mostly that's great, but in this case it's a problem and pushing it much further is going to be a problem. It's also going to be weird if the default never change, then we just have a C library that that just keep producing defective programs, unless you add certain flags.
- rjsw 5y agoOpenBSD was the slowest of the major BSD systems to switch. NetBSD made the change in 2009, it also preserves backward compatibility.
- mrweasel 5y agoI did not know that. The OpenBSD change just stuck in my head somehow. Any idea how NetBSD fixed the backward compatibility?
- mlyle 5y agoNetBSD provides a binary compatibility layer clear back to ancient NetBSD versions. If your NetBSD binary targeted a version before 6.0, it gets the compatibility stubs like http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/compat/time/compat_difftime.c?annotate=1.2 http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/compat/time...
- dtech 5y agoThe default always was 64-bit for 64-bit systems, so this isn't as big of an issue at the blog posts makes it out to be.
- mrweasel 5y agoThere are a large amount of 32bit devices still being designed and built. Not for servers, desktops or laptops, but embedded devices, controllers and so on. These are actually the worst device to have the issue in, because they will last longer than 2038. If you ship an 32bit embedded device today, there's a reasonable chance that that device will be in service 20 years for now.
- PixelOfDeath 5y ago> The GNU and Linux world is really good at not breaking ABI compatibility ... If you exclude like every user land library there is (including the glibc)
- AnssiH 5y agoIsn't glibc, specifically, very careful about ABI compatibility? You can still run Linux programs linked against decades-old versions of glibc on current systems as they have kept ABI compatibility with the use of symbol versioning, without changing their SONAME ("libc.so.6"). Sure, that does not extend to being able running programs linked against new glibc symbols on old systems, but if you consider that ABI-breaking then the Linux kernel would also be ABI-breaking as you cannot run binaries relying on new kernel syscalls (etc) on older Linux kernels.
- PixelOfDeath 5y agoDebConf14: Linus about breaking librarie-ABIs: https://www.youtube.com/watch?v=Pzl1B7nB9Kc&t=168s https://www.youtube.com/watch?v=Pzl1B7nB9Kc&t=168s
- GoblinSlayer 5y agoglibc itself doesn't break ABI, it provides both 32-bit and 64-bit functions, just defaults to the wrong portion of them on the C API level.