3 ms·

Are you going to rewrite 5 decades worth of legacy software to use it?

alkonaut 5y ago
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.
- rwaksmunski 5y ago
  Yes, the alternative to rewriting is changing the size and recompiling. OpenBSD somehow managed to pull it off.
  - alkonaut 5y ago
    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?
    - rwaksmunski 5y ago
      Yes, stuff broke in the ports collection. Not sure about planes but at least one monitor exploded.
      - alkonaut 5y ago
        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.
strenholme 5y ago
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.
- rwaksmunski 5y ago
  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.
  - strenholme 5y ago
    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.

rwaksmunski 5y ago
Yes, the alternative to rewriting is changing the size and recompiling. OpenBSD somehow managed to pull it off.
- alkonaut 5y ago
  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?
  - rwaksmunski 5y ago
    Yes, stuff broke in the ports collection. Not sure about planes but at least one monitor exploded.
    - alkonaut 5y ago
      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.

strenholme 5y ago

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.

rwaksmunski 5y ago
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.
- strenholme 5y ago
  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.