Linked by Thom Holwerda on Sun 9th Jul 2017 08:59 UTC
BeOS & Derivatives

time_t now uses 64-bit on 64-bit systems. This fixes the year 2038 bug for 64-bit Haiku, so we can continue to run it after 2038. This breaks the ABI, so all the 64bit packages were rebuilt.

As Michel points out in the comments, this means Haiku'll be good until 4 December 292277026596, about in time for the beta release.

Thread beginning with comment 646511
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: 2038
by BlueofRainbow on Mon 10th Jul 2017 11:45 UTC in reply to "2038"
BlueofRainbow
Member since:
2009-01-06

From what I understand, fixing the Y2038 issue required "breaking" the Application Binary Interface (ABI).

The fix was applied to Haiku-64bit. All applications included in the nightly build were recompiled.

The fix was not applied to Haiku-32bit as this would break compatibility with the BeOS applications still in circulation. It is quite possible that BeOS it-self (and by extension Zeta) have the same issue.

Reply Parent Score: 2

RE[2]: 2038
by JLF65 on Mon 10th Jul 2017 17:21 in reply to "RE: 2038"
JLF65 Member since:
2005-07-06

They'll need to eventually make two ABIs for 32-bit. One will be backwards compatible to allow running old programs that won't break due to the bug; the other will have a minor change to the ABI only affecting the bug. The easiest way to deal with the bug after 2038 would be to have the time freeze right before the date that wraps around. So old 32-bit programs would get the same date from then on, while 32-bit programs compiled with the new ABI will get the proper date.

Dealing with two ABIs for 32-bit shouldn't be much of a hassle - both MacOS and Windows have done that a number of times, going as far as to have "FAT" binaries that handle both in the same executable. It's a kludge, but some problems can only be effectively dealt with by a kludge.

Reply Parent Score: 2