Status of 2038 bug on IRIX?

IRIX and IRIX software discussion including open source and commerical offerings.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
cesss
Posts: 100
Joined: Mon Apr 27, 2009 8:02 am

Status of 2038 bug on IRIX?

Unread postby cesss » Wed May 18, 2016 12:31 pm

Hi,

What's the status of the 2038 issue on IRIX? Is time_t 64 bit on IRIX64? For all IRIX64 releases, or only starting with some version?

Does the issue affect 32 bit IRIX only? Did they release any workaround for 32 bit IRIX at some point?

Thanks!

User avatar
Krokodil
Donor
Donor
Posts: 478
Joined: Fri Apr 17, 2015 2:32 pm
Location: The House of Particular Individuals

Re: Status of 2038 bug on IRIX?

Unread postby Krokodil » Wed May 18, 2016 12:37 pm

Will any machines that ran 32 bit IRIX still be operational by 2038? Will any SGI machines still be operational by then? IRIX will be certainly be so crusty by then that it won't be very usable.
Last edited by Krokodil on Wed May 18, 2016 1:34 pm, edited 4 times in total.
:Octane2: - :O2: - :Octane: - :Indigo2IMP:

cesss
Posts: 100
Joined: Mon Apr 27, 2009 8:02 am

Re: Status of 2038 bug on IRIX?

Unread postby cesss » Wed May 18, 2016 12:46 pm

Krokodil wrote:Will any machines that ran 32 bit IRIX still be operational by 2038? Will any SGI machines still be operational by then? IRIX will be certainly be so crusty by then that it won't be very usable.

That wasn't my question.

User avatar
Krokodil
Donor
Donor
Posts: 478
Joined: Fri Apr 17, 2015 2:32 pm
Location: The House of Particular Individuals

Re: Status of 2038 bug on IRIX?

Unread postby Krokodil » Wed May 18, 2016 2:31 pm

cesss wrote:
Krokodil wrote:Will any machines that ran 32 bit IRIX still be operational by 2038? Will any SGI machines still be operational by then? IRIX will be certainly be so crusty by then that it won't be very usable.

That wasn't my question.


And you're missing the point.

By 2038 (23 years from now), everything 32bit from the Professional IRIS, up to the last SGI O2's produced, will be atleast 36 years old and very likely out of service. This forum will be probably be gone too.

Then there's the software issue, although IRIX64 probably does have the time_t in it, 32 bit does not and unless someone decides to modify and recompile one of the illegal source code bundles floating around "out there", and then you still have no recourse for dealing with the 3rd party programs and their licenses that were never upgraded to deal with that.

Don't worry about 2038 and IRIX. Just enjoy the machines while they still work and are serviceable.
:Octane2: - :O2: - :Octane: - :Indigo2IMP:

User avatar
japes
Donor
Donor
Posts: 1006
Joined: Thu Nov 08, 2007 4:35 pm
Location: Lynnwood, WA

Re: Status of 2038 bug on IRIX?

Unread postby japes » Wed May 18, 2016 3:25 pm

While I appreciate that keeping a machine running for another 22 years is going to be a challenge, I know someone will probably do it. Look at the computer history museums that are getting old CDC machines and IBM Mainframes working before all the guys that know how to service them die off. Look at the PDP 8 and other DEC minicomputer machines I know hobbyists and museums are running.

More important, bugs like the 2038 and year 2000 are issues well before the year comes up if you do any forecasting, modeling etc of time-series data. So I believe it's valuable to address the original question, not dismiss the machines as boat anchors.

If you just want to enjoy an old machine it probably doesn't matter that much as nothing says the data has to be set correctly.
:O3000: :Fuel: :Tezro: :Tezro: :Octane2: :Octane: :Octane: :Indigo: :Indigo: :Indigo: :Indigo: :O2: :1600SW: :O2: :1600SW: :1600SW: :Indigo2: :Indigo2: :Indigo2: :Indigo2: :Indigo2IMP: :Indy: :Indy: :Indy: :Indy: :O3x0: :O3x02L: :O3x02L:

User avatar
Krokodil
Donor
Donor
Posts: 478
Joined: Fri Apr 17, 2015 2:32 pm
Location: The House of Particular Individuals

Re: Status of 2038 bug on IRIX?

Unread postby Krokodil » Wed May 18, 2016 4:41 pm

japes wrote:While I appreciate that keeping a machine running for another 22 years is going to be a challenge, I know someone will probably do it. Look at the computer history museums that are getting old CDC machines and IBM Mainframes working before all the guys that know how to service them die off. Look at the PDP 8 and other DEC minicomputer machines I know hobbyists and museums are running.

More important, bugs like the 2038 and year 2000 are issues well before the year comes up if you do any forecasting, modeling etc of time-series data. So I believe it's valuable to address the original question, not dismiss the machines as boat anchors.


That works for those old machines, because their components are quite large and can be replaced. But with newer computers, repairing the hardware like that is almost impossible, due to the size of the individual components. Some of the components on this O2 system board are less than the size of a pin head.

japes wrote:More important, bugs like the 2038 and year 2000 are issues well before the year comes up if you do any forecasting, modeling etc of time-series data. So I believe it's valuable to address the original question, not dismiss the machines as boat anchors.


Well I hate to say it, but some of them are boat anchors, they look cool, but they can't do much useful work anymore. Some outfits might have an application running on them that they won't let go of, but eventually something has to give.

I wish you luck finding a solution to the 2038 problem in 32 bit IRIX though. I will be interested to see what comes of it.
:Octane2: - :O2: - :Octane: - :Indigo2IMP:

User avatar
ClassicHasClass
Donor
Donor
Posts: 2108
Joined: Wed Jul 25, 2012 7:12 pm
Location: Sunny So Cal
Contact:

Re: Status of 2038 bug on IRIX?

Unread postby ClassicHasClass » Wed May 18, 2016 6:37 pm

I'd actually done some thinking about this, because I imagine some of my Power Macs will be alive by then. The Commodore 128DCR next to me is about 30 years old. The Rev A MOS KIM-1 in the closet is older than I am.

It seems like the most straightforward solution is to advance the epoch from 1970 to a later date. That would require patching libc so that functions like ctime(), gmtime(), etc., all are rebased on the new epoch (my guess is there's one location where this is computed, so changing that should make everything else work, but that's just my guess). Thinking out of my butt here, setting it to something like 1990 should do the job, and would be sufficient for reasonable historical dates. Naturally there would be side effects like suddenly all your files becoming 20 years newer, though you could overcome that specific issue with a script to recompute the mod times.
smit happens.

:Fuel: bigred, 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
:Indy: indy, 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze, 175MHz R10000, Solid IMPACT
probably posted from Image bruce, Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * RDI PrecisionBook * BeBox * Solbourne S3000 * Commodore 128 * many more...

cesss
Posts: 100
Joined: Mon Apr 27, 2009 8:02 am

Re: Status of 2038 bug on IRIX?

Unread postby cesss » Wed May 18, 2016 9:52 pm

So, nobody can confirm if sizeof(time_t)==8 on IRIX64 nor provide some hints about the questions in the original post? I agree discussing if IRIX will exist in 2038 can be a long and interesting topic, but, however, that's completely (and I mean completely) unrelated to my original question, which is the status of IRIX regarding the 2038 issue, and if it affects both IRIX64 and IRIX 32 bit, only one of them, or if any patches/workarounds were proposed by SGI. Also, in case IRIX64 isn't affected, knowing if this is true for all IRIX64 releases or only for some of them would be interesting to know.

User avatar
vishnu
Donor
Donor
Posts: 3189
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: Status of 2038 bug on IRIX?

Unread postby vishnu » Wed May 18, 2016 10:27 pm

cesss wrote:So, nobody can confirm if sizeof(time_t)==8 on IRIX64 nor provide some hints about the questions in the original post? I agree discussing if IRIX will exist in 2038 can be a long and interesting topic, but, however, that's completely (and I mean completely) unrelated to my original question, which is the status of IRIX regarding the 2038 issue, and if it affects both IRIX64 and IRIX 32 bit, only one of them, or if any patches/workarounds were proposed by SGI. Also, in case IRIX64 isn't affected, knowing if this is true for all IRIX64 releases or only for some of them would be interesting to know.

A workaround was implemented by SGI; they EOLed Irix. As far as they're concerned that's problem solved. :roll:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
jan-jaap
Donor
Donor
Posts: 4939
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands
Contact:

Re: Status of 2038 bug on IRIX?

Unread postby jan-jaap » Thu May 19, 2016 12:10 am

cesss wrote:So, nobody can confirm if sizeof(time_t)==8 on IRIX64 nor provide some hints about the questions in the original post?

Hey, there's the occasional evening I'm not around my computers :)

Code: Select all

#include <stdio.h>
#include <sys/time.h>

int main(void)
{
   printf("sizeof(time_t) = %lu bits\n", sizeof(time_t)*8);
   return 0;
}

Output on IRIX64 6.5.30 (for both N32 and 64bit ABIs):

Code: Select all

sizeof(time_t) = 32 bits

None is this is much of a surprise because in <sys/time.h> the type time_t is explicitly declared 32bits:

Code: Select all

/* needed here according to MIPS ABI draft */
#ifndef _TIME_T
#define _TIME_T
#if _MIPS_SZLONG == 32
typedef long            time_t;         /* <time> type */
#endif
#if _MIPS_SZLONG == 64
typedef int             time_t;         /* <time> type */
#endif
#endif /* !_TIME_T */
:PI: :Indigo: :Indigo: :Indy: :Indy: :Indy: :Indigo2: :Indigo2: :Indigo2IMP: :Octane: :Octane2: :O2: :O2+: Image :Fuel: :Tezro: :4D70G: :Skywriter: :PWRSeries: :Crimson: :ChallengeL: :Onyx: :O200: :Onyx2: :O3x02L:
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

User avatar
Krokodil
Donor
Donor
Posts: 478
Joined: Fri Apr 17, 2015 2:32 pm
Location: The House of Particular Individuals

Re: Status of 2038 bug on IRIX?

Unread postby Krokodil » Thu May 19, 2016 1:06 am

Wonderful to find out that even IRIX64 will not escape from the wrath to come.

Thanks SGI, what a great final middle finger to your loyal fans.
:Octane2: - :O2: - :Octane: - :Indigo2IMP:

cesss
Posts: 100
Joined: Mon Apr 27, 2009 8:02 am

Re: Status of 2038 bug on IRIX?

Unread postby cesss » Thu May 19, 2016 2:22 am

Thanks a lot, jan-jaap. BTW, are ints 32bit on the N64 ABI? And I know you did it, but just to be sure, can you check you have -n64 on the compiler invocation line?

User avatar
jan-jaap
Donor
Donor
Posts: 4939
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands
Contact:

Re: Status of 2038 bug on IRIX?

Unread postby jan-jaap » Thu May 19, 2016 3:36 am

cesss wrote:are ints 32bit on the N64 ABI? And I know you did it, but just to be sure, can you check you have -n64 on the compiler invocation line?

Yes, 'int' is always 32bits, but pointers and 'long' are 64bits (on the 64 ABI, not on N32). Techpubs used to have an N32/64 porting guide of some sort which explains all of that.

My compiler is MIPSpro, so I had to use '-64', not '-n64' but yeah, I checked just to make sure my brain still works ;)
:PI: :Indigo: :Indigo: :Indy: :Indy: :Indy: :Indigo2: :Indigo2: :Indigo2IMP: :Octane: :Octane2: :O2: :O2+: Image :Fuel: :Tezro: :4D70G: :Skywriter: :PWRSeries: :Crimson: :ChallengeL: :Onyx: :O200: :Onyx2: :O3x02L:
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

cesss
Posts: 100
Joined: Mon Apr 27, 2009 8:02 am

Re: Status of 2038 bug on IRIX?

Unread postby cesss » Thu May 19, 2016 8:33 am

Thanks a lot, jan-jaap, this makes it all clear. I guess the reason might be that some OS tools were still built as 32 bit even when running on IRIX64, and so it made no sense to have some binaries with 32bit time_t and others with 64bit time_t running at the same time on the same machine. Thanks.

User avatar
ClassicHasClass
Donor
Donor
Posts: 2108
Joined: Wed Jul 25, 2012 7:12 pm
Location: Sunny So Cal
Contact:

Re: Status of 2038 bug on IRIX?

Unread postby ClassicHasClass » Thu May 19, 2016 9:03 am

AIX kind of handles that well. My POWER6 machine has a 64-bit time_t, though some of the *time() functions still have a Y2038 problem, at least in 6.1. But applications can be unaware of it if they want to be (or aren't designed to be aware of it).

Anyway, I pondered this a bit on my PowerPC OS X machines. There are a couple places in the BSD time functions stored in libSystem.B.dylib in 10.4.11 where you can find a naked 1970 and 2037 (stuff like li r0, 0x7b2) so you'd just patch those instructions. Likely the most optimal year to switch to would be any that's the same calendar as 1970, so 1987 or 1998 would be possible choices. 1998 seems a little late so I'm thinking 1987.

I can't imagine a similar approach couldn't be tried for IRIX.
smit happens.

:Fuel: bigred, 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
:Indy: indy, 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze, 175MHz R10000, Solid IMPACT
probably posted from Image bruce, Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * RDI PrecisionBook * BeBox * Solbourne S3000 * Commodore 128 * many more...


Return to “IRIX and Software”

Who is online

Users browsing this forum: No registered users and 1 guest