Slashdot Mirror
The BBC Looks At Rollover Bugs, Past and Approaching
New submitter Merovech points out an article at the BBC which makes a good followup to the recent news (mentioned within) about a bug in Boeing's new 787. The piece explores various ways that rollover bugs in software have led to failures -- some of them truly disastrous, others just annoying. The 2038 bug is sure to bite some people; hopefully it will be even less of an issue than the Year 2000 rollover. From the article:
It was in 1999 that I first wrote about this," comments [programmer William] Porquet. "I acquired the domain name 2038.org and at first it was very tongue-in-cheek. It was almost a piece of satire, a kind of an in-joke with a lot of computer boffins who say, 'oh yes we'll fix that in 2037' But then I realised there are actually some issues with this.
It's not a rollover bug; It's a rollover feature!
You do not have a moral or legal right to do absolutely anything you want.
If you reuse code, you get rollover bugs.
If you start over from scratch you get brand new bugs.
Reusing the code, you have a lot of the issue from the past already fixed, so you are not introducing bugs that you had in the past.
Making new code, you can modernise the code set, so you don't run into particular troubled code, and is easier to follow.
Programmers are human beings, they make mistakes, they can't give 110% every day. Even the best of them will often have a stupid bug, that they can't believe that they had slip.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Since the OpenBSD 5.5 release a year ago, the OS is fully ready for the onslaught of 2038.
http://news.cnet.com/2100-1040...
Minuteman III nuclear missile: Due to an unsigned integer bug, missile resets to the year 1900 and targets Grover Clevelands presbyterian ministry as part of the clandestine war on christmas
US Presidential Limousine: Function call returns a flawed short int that causes the vehicle to lose entropy in its timekeeping, routinely deploying countermeasures and refusing to operate in the presence of a black president.
UCLA Scheduling mainframe: strconv slurps an undersized signed int, causing date/time tracking problems and resulting in comfortable, plausible and very useful class scheduling to occur.
Russian RT-23 Molodets missile: timer returns a null or negative value, resulting in an active launch thats aborted by sergei usually after he has his first cup of coffee...but sometimes after the paper.
Good people go to bed earlier.
Given that so much of the GNU/Linux code base is written by volunteers I wonder who it is exactly that is going to fix all of the code. I mean back when it was written Computer programming was much less of a gold rush. Nowadays everyone is competing for jobs that pay $120,000. Who is willing to go through all of the old code and fix it for free?
when we had an equipment malfunction and our data logger's time stamped data made no sense - one second we were recording values of x and the next second normal values. Turned out the daylight savings time switch had occurred during the incident and as a result all the time stamps and resulting data were screwed up.
I'm a consultant - I convert gibberish into cash-flow.
There is no chance whatever of the code being replaced if its working now, because no one will sign off a replacement if it still works.
Sent from my ASR33 using ASCII
Isn't mouseover the modern term?
There was a counter in Windows that rolled over after 28 days I think (like the 787 bug, but 1000 ticks.second not 100).
Even Microsoft knew that no Windows box could stay up that long.
(And before you mod me as a troll, think about it and know that MS could have made a bigger counter, but didn't feel the need to)
Several years ago I was really concerned about the 2038 rollover because so many protocols have hard baked 32 bit timestamp fields in them. Even if systems were updated the protocols might not be. But I've come to realize that once the systems are updated, the protocol tend to follow suit in the next revision, and in the next 23 years pretty much every protocol is going to go through at least one revision. There are still going to be a few holdouts that have trouble in 2038, but I'm expecting it to be as much of an event as the year 2000. A few fringe things act weird or even stop working, but pretty much everything important is OK.
I read the internet for the articles.
I will be retiring in 2030, so not my problem.
...because I'm going to be in a fucking jar on a shelf in 2038.
So Is Mac OS X.
I converted time_t to 64 bits on 64 bit systems (which include the most recent iPhones) as part of the changes for 64 bit binary support on the G5 when I wrote the 64 bit binary loader support into exec/fork/spawn, and again as part of UNIX Conformance. It's basically been fixed since Tiger.
The reason so little went wrong is because people spent ages testing and upgrading/fixing beforehand. Had we left it all to 1st Jan 2000 there would have been issues,
It annoys me to see Y2K trotted out time and time again as a non-event. It was a very big event, and by the large part it was very successfully handled.
I love the way that the entire world-o'-geeks gets upset about a triviality. What prevents future *NIX releases from changing the "base date" to, say, 2010, and changing all the dependent modules to compute properly? Are there to be no future *NIX releases between now an 2038?
Are there programmers who, in their cleverness, have use primitive code that still relies on the older base date without reference to the underlying O.S.? Sure. But, change the base date soon, and all their bugs will appear LONG before 2038, but they'll be individual and isolated, and easily identified.
Geez. Much ado about NOTHING. This sounds more like an out-of-sync April Fool's joke than a serious problem...or, was that the original point?
Yes, the average age of an American or Russian COBOL programmer will be 80 or over by 2038... However, you're discounting the Filipinos...
Most of those kids are in their late 20's at most, so they'll be around in 2038. Assuming our Mainframe isn't phased out due to budget cuts, I suspect that the code written in 1980 will still be maintained and running well past 2038.
If telephones are outlawed, then only outlaws will have telephones.
"I question a management culture that appeared to assume that the rocket’s inertial reference system that functioned perfectly when fitted into Ariane4 would achieve the same results when fitted into Ariane5." ref
Thanks to the math required for date conversion, the 2038 bug may actually show up a couple of years early. How do I know? I tried setting the clock forward in an embedded system I wrote the code for. Its calendar actually seems to fail in 2036. I haven't tried it in a while, but I think I can't even set the date past January 2036. I didn't try to figure out exactly why it failed earlier than it should have, because the library code looks pretty messy.
It's using the standard date library stuff from the IAR compiler, so I'm hoping that sometime within 20 years there will be an option to select a 64-bit compatible time/date library, and it can just be recompiled. At least I used time_t for everything related to Unix date values... I think. Also, the hardware it runs on only has a 32-bit counter for the RTC clock, but I'm sure that it could simply check the high bit, and add 2^32 after the rollover.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }