And they dropped the approach because few to none were going to rewrite existing code to add support for non-standard extensions to fix 40 years out issues. Instead they moved to 64b time_t in 10.7 I think?
And it’s not a new call, dozens of functions touch time_t, plus a few syscalls.
64b code does not necessarily imply 64b time_t though. If your time_t is an alias for int, it's 32b on anything short of (S)ILP64, which is anything but common. I'm not sure there's been any other than Cray's UNICOS and HAL's Solaris port.
This is exactly what glibc did. If you want you can use the 64-bit types and symbols directly. The _TIME_BITS=64 macro redefines the standard C & POSIX time things to point to the 64-bit variants, so you can just recompile code to use them.
For open source software, it’s a simple recompile. Most OSS compiles are 64-bit these days, where time_t has always been 64-bit. In the case of compiling a new 32-bit application, -D_TIME_BITS=64 apparently needs to be a compile time flag.
For binary software, Windows has had a Y2038 compliant proprietary API since Windows NT in the 1990s; most Windows applications use this API so Y2038 is generally not an issue.
The issue only affects a subset of 32-bit binary-only applications where we don’t have the source code any more. Hopefully, any and all applications like that will be decommissioned within the next couple of years.
I think you misread the root comment, it suggests a new function call that no one will use. Apple made that mistake, then they just switched the size and dealt with the fallout.
Looks like I lost the context. In terms of the context:
The issue is, besides having to rewrite code, it’s not just one function. It’s time_64(), but now we need gmtime_64(), strftime_64(), stat_64(), and so on for any and all functions which use timestamps.
The thinking in Linux land is that we won’t have 32-bit applications come 2038 where this matters, because everything will be 64-bit by then.
What’s the alternative to rewriting? Just recompiling?
Assuming the code on the receiving end stores the value in 32 bits (and not a time _t which can magically change meaning but a 32 bit integer) then it’s still doomed without rewrite?
I mean even with time_t use you can’t just recompile and make it work because there could be subsequent assumptions that the size of a struct containing a time_t will be a specific size or allocations will be too small or misaligned and so on.
But the problem isn't really changing the OS to return a 64bit value where it used to return 32, the problem is all the applications that assumed it would be 32.
By "pulling it off" you mean, they changed it and planes didn't crash around them?
That still seems like software under the “control” of the OS maintainers. But most apps running on an OS are never seen by the people maintaining the OS.
That’s why it’s such a tricky move to break compat with those apps X because you cant know what they are doing and how.
