Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Exact Cause of the Zune Meltdown

kdawson posted more than 5 years ago | from the off-by-one-every-four dept.

Microsoft 465

An anonymous reader writes "The Zune 30 failure became national news when it happened just three days ago. The source code for the bad driver leaked soon after, and now, someone has come up with a very detailed explanation for where the code was bad as well as a number of solutions to deal with it. From a coding/QA standpoint, one has to wonder how this bug was missed if the quality assurance team wasn't slacking off. Worse yet: this bug affects every Windows CE device carrying this driver."

cancel ×

465 comments

Sorry! There are no comments related to the filter you selected.

Why is this a surprise? (0, Troll)

deanston (1252868) | more than 5 years ago | (#26323727)

And who uses Windows CE?

Re:Why is this a surprise? (3, Informative)

panoptical2 (1344319) | more than 5 years ago | (#26323965)

As Wikipedia would have it here [wikipedia.org] ...

Windows Mobile is best described as a subset of platforms based on a Windows CE underpinning. Currently, Pocket PC (now called Windows Mobile Classic), SmartPhone (Windows Mobile Standard), and PocketPC Phone Edition (Windows Mobile Professional) are the three main platforms under the Windows Mobile umbrella. Each platform utilizes different components of Windows CE, as well as supplemental features and applications suited for their respective devices.

So, every smartphone/PDA that currently uses Windows Mobile uses some form of CE.

Re:Why is this a surprise? (1)

jcarkeys (925469) | more than 5 years ago | (#26324109)

But none of the devices that use Windows Mobile also use this driver.

firstest (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26323729)

poast

Wow. (4, Funny)

LeadLine (1278328) | more than 5 years ago | (#26323741)

It wasn't a bug! It was an unexpected feature!

Microsoft is taking a stance against teenagers blowing their ears out with loud music.

Re:Wow. (1)

XPeter (1429763) | more than 5 years ago | (#26323827)

Hey! I'm a teenager who proudly blows my ears out with Metallica daily, you insensitive clod!

Re:Wow. (4, Funny)

Vadatajs (1367737) | more than 5 years ago | (#26323855)

Teenagers these days are too young to remember metallica.

Re:Wow. (4, Funny)

Yvan256 (722131) | more than 5 years ago | (#26323883)

They're too busy listening to NiMHica.

Re:Wow. (1)

MartinSchou (1360093) | more than 5 years ago | (#26324407)

I would have gone for Meitnerium Tantalum Lithium Calcium

Re:Wow. (0)

Anonymous Coward | more than 5 years ago | (#26324041)

Teenagers these days are too young to remember metallica.

you know they did just release a new album...

Re:Wow. (5, Funny)

Anonymous Coward | more than 5 years ago | (#26324235)

No they didn't no they didn't lalalala I can't hear you That piece of shit was definitely not any Metallica I know.

Re:Wow. (2, Funny)

stonedcat (80201) | more than 5 years ago | (#26324059)

Hey, if he wants to blow Metallica then by all means, let him.

Who are we to stand in the way of his dreams?

Old (-1, Troll)

thetoadwarrior (1268702) | more than 5 years ago | (#26323743)

This has been covered numerous times already.

Re:Old (0)

Anonymous Coward | more than 5 years ago | (#26323853)

You know there's a problem when Digg covers this technology news before Slashdot.

Re:Old (3, Interesting)

LostCluster (625375) | more than 5 years ago | (#26323857)

Yep, but it deserves to be covered so that everybody hears it. It's not just a laugh at Microsoft story, but also a lesson to aspiring programmers to watch there step when it comes to timekeeping. Gotta get a mention to the people who look at /. at work, gotta get a mention to the people who visit weeknights, gotta mention it for the weekend crowd.

Re:Old (5, Insightful)

larry bagina (561269) | more than 5 years ago | (#26324019)

Comments in the last zune slashdot story (yesterday?) were just as detailed as this "story". Maybe slashdot editors should read their own site. Or maybe I should start submitting all +5 comments for their own story.

Not from what I saw. (0)

Anonymous Coward | more than 5 years ago | (#26324201)

Really? I didn't see many examples of alternate solutions to this.

Warning, Y2.1K bug. (3, Informative)

LostCluster (625375) | more than 5 years ago | (#26323749)

Just before anybody claims to have a foolproof solution to leap years, make sure you test against the year 2100. It's a multiple of four, but also a multiple of 100 that's not a multiple of 400... and therefore NOT a leap year.

Re:Warning, Y2.1K bug. (2, Funny)

Yvan256 (722131) | more than 5 years ago | (#26323781)

What about other years which are multiples of four, also multiples of 100 but not multiples of 400?

Re:Warning, Y2.1K bug. (5, Informative)

LostCluster (625375) | more than 5 years ago | (#26323829)

Here's your 500 year plan:

1900 - multiple of 100, not a multiple of 400, no leap day.
2000 - was a multiple of 100, but also a multiple of 400 so we still had a leap day.
2100 - see above
2200 - not a multiple of 400, no leap day.
2300 - not a multiple of 400, no leap day
2400 - multiple of 400, so have the leap day anyway.

Re:Warning, Y2.1K bug. (2, Insightful)

Gothmolly (148874) | more than 5 years ago | (#26323859)

No need to hard-code, there's an established algorithm for computing this.

Re:Warning, Y2.1K bug. (0, Troll)

LostCluster (625375) | more than 5 years ago | (#26323881)

Okay, tell the programming instructors that there's no need to teach Hello World examples, because there's already code that does that.

Re:Warning, Y2.1K bug. (3, Insightful)

narcberry (1328009) | more than 5 years ago | (#26323913)

I think you missed the point.

Re:Warning, Y2.1K bug. (0)

Anonymous Coward | more than 5 years ago | (#26323865)


year=2100;
leap = false;
if ((year %4 )==0) leap=true;
if ((year %100)==0) leap=false;
if ((year %400)==0) leap=true;

this works

Re:Warning, Y2.1K bug. (2, Funny)

gcnaddict (841664) | more than 5 years ago | (#26323923)

It won't matter:

#define ORIGINYEAR 1980 // the begin year
#define MAXYEAR (ORIGINYEAR + 100) // the maxium year

Re:Warning, Y2.1K bug. (1)

jrumney (197329) | more than 5 years ago | (#26324101)

In a consumer electronics product that's launching anytime before about 2075, I don't think I'd bother. Remember all the software that needed fixing for 2000 because some idiot had put in the 100 year rule without the 400 year rule? Would have been much better to just keep it simple and reduce your list of things to go wrong.

Re:Warning, Y2.1K bug. (0)

Anonymous Coward | more than 5 years ago | (#26324217)

This isn't important only on products that are to be used on year 2100. I - as someone who is not a programmer - would imagine this thing to come up as one way or another on any software handling dates at/past that point. And it is easy to imagine that kind of software.

Re:Warning, Y2.1K bug. (2, Insightful)

gcnaddict (841664) | more than 5 years ago | (#26324405)

The code in the freescale driver actually covers this. Check the IsLeapYear() function in the code (line 162):

static int IsLeapYear(int Year)
{
int Leap;

Leap = 0;
if ((Year % 4) == 0) {
Leap = 1;
if ((Year % 100) == 0) {
Leap = (Year%400) ? 0 : 1;
}
}

return (Leap);
}

If this interests you (1)

dmomo (256005) | more than 5 years ago | (#26323799)

And you are a programmer, I would highly recommend the book Deep C Secrets [amazon.com] . It's partly practical and partly culture. It covers some well (and lesser) known bugs that while very small and "stupid" had very real consequences.

Re:If this interests you (3, Informative)

Creepy Crawler (680178) | more than 5 years ago | (#26323847)

Amazon link eh? meh.

Try this link for your "sampling" : Deep C Secrets [rapidshare.com] .

Took only 15 seconds for that link. Enjoy.

Re:If this interests you (0)

Anonymous Coward | more than 5 years ago | (#26323939)

15 seconds was not long enough. You should have checked that thing first.

Free Book web site. (3, Informative)

Futurepower(R) (558542) | more than 5 years ago | (#26324193)

Wow. That link is to a book from a good web site: Free eBooks [free-ebooksnet.com] .

Other free books about C and C++: Free C and C++ books [free-ebooksnet.com]

Some has came up? (0)

Anonymous Coward | more than 5 years ago | (#26323839)

Methinks it was the same f*cked up code monkey that wrote this summary!

Import calendar? (5, Insightful)

TurtleBlue (202905) | more than 5 years ago | (#26323841)

"From a coding/QA standpoint, one has to wonder how this bug was missed if the quality assurance team wasn't slacking off."

I can't remember the last time a QA department was asked to test date functions... but then again, I can't remember the last time anyone wrote their own Leap Year calendaring calculator from scratch.

I'm sure there are a hundred reasons to do it (licensing being one of them) but really, when was the last time you didn't just import calendaring from another library and call it a day?

Please clarify to me if this is something at the hardware driver level: I honestly don't know. If this were me, my own bosses wouldn't ask "Why didn't QA catch this", as much as "why are you wasting time writing your own calendar code? And then why didn't you flag it as functionality that needed to be tested?"

Re:Import calendar? (2, Interesting)

gcnaddict (841664) | more than 5 years ago | (#26323901)

Well, that might explain why the same clock doesn't exist in the subsequent Zunes, but who knows.

I'm more disturbed by one of the comments [aeroxp.org] and the subsequent reply.

Re:Import calendar? (2, Insightful)

nedlohs (1335013) | more than 5 years ago | (#26323929)

FOr fuck sake, how do you manage to read that part and not read the part before it: "source code for the bad driver".

The QA person/people testing the driver for the real time clock better damn well be testing date and time stuff.

Re:Import calendar? (5, Informative)

Anonymous Coward | more than 5 years ago | (#26323953)

It is driver code supplied by the manufacturer of the hardware platform on which the Zune and a couple of other devices are built. This platform includes a real-time clock which counts seconds since midnight and days since 1/1/1980. Considering that hardware component prices are cut-throat, there is probably no quality management for the software whatsoever. If it appears to work, it ships.

Re:Import calendar? (5, Insightful)

TurtleBlue (202905) | more than 5 years ago | (#26324099)

Thanks - that makes a tad more sense. I see everyone running around blaming Microsoft for the code since their name is on the product, even if it was a 3rd party vendor. They certainly are still liable for all the busted Zunes, but I couldn't imagine Microsoft didn't have *some* C leap-year code sitting around that actually worked, and could be compiled for any chip they wanted.

Microsoft still has to take the hit up front, but then they'll sue or "renegotiate contracts" with the vendor that supplied the bad driver code, based on what it costs them.

I'm still shocked that the manufacturer couldn't dig up *some* free/open calendaring code that's was around pre-2004. But hey, at least we know they were honest about not ripping off some other source code and calling it their own.

Re:Import calendar? (5, Informative)

nato10 (600871) | more than 5 years ago | (#26324123)

This is kernel-level code -- part of the OEM Abstraction Layer -- that is used to read the current time from the RTC, hence it is hardware-specific. RTCs on other processors, or Freescale-based devices using external RTCs, may implement the OemGetRealTime () function differently than Freescale has done here (the buggy ConvertDays () function is just a helper function).

Re:Import calendar? (0)

Anonymous Coward | more than 5 years ago | (#26324257)

More than likely MS didnt even write the code. Some third part did. Their whole driver infrastructure is just built that way... Their test system is just not ready for this sort of thing (it should be). Trust stress out CE a little bit and it starts acting REALLY oddly.

Dont blame MS here is who you should blame...
'Copyright (C) 2004-2007, Freescale Semiconductor'

Re:Import calendar? (0)

Anonymous Coward | more than 5 years ago | (#26324363)

But would you call it a day or a day+1 if it was a leap year?

"Leaked"...? (5, Informative)

Anonymous Coward | more than 5 years ago | (#26323843)

It's an open source driver from Freescale.

Why write any date/time code? (1)

chafey (108827) | more than 5 years ago | (#26323889)

My first reaction to this is wondering why anyone would decide to write their own date/time code. I would expect there to be several good options for open source date/time code that is mature and proven to work right.

Re:Why write any date/time code? (5, Informative)

p0tat03 (985078) | more than 5 years ago | (#26323981)

This was written by the Freescale guys, not MS, where it would make sense for the device manufacturer to ship their own date/time code.

MOD PARENT UP Re:Why write any date/time code? (5, Insightful)

exphose (1261624) | more than 5 years ago | (#26324029)

Exactly, just goes to show the dangers in not QA'ing the whole codebase including supplied drivers. You can't trust your own code so you QA it, why should you trust your partner's code.

Re:MOD PARENT UP Re:Why write any date/time code? (1)

p0tat03 (985078) | more than 5 years ago | (#26324069)

And an example of where closed-source binary drivers can go horribly wrong :) But really, no one can be expected to QA every single line of code that's shipped through their device (honestly, a date function fuckup?)... what this really says is the importance of proper QA at the driver-developer level.

Re:MOD PARENT UP Re:Why write any date/time code? (0)

Anonymous Coward | more than 5 years ago | (#26324105)

This happened to be an open source driver though.

Re:Why write any date/time code? (3, Insightful)

cbhacking (979169) | more than 5 years ago | (#26324323)

Ah, thank you. This explains better why the 2nd-gen and 3rd-gen Zunes didn't suffer this problem; they were completely designed and developed in-house.

QA team slacking off... (4, Funny)

feepness (543479) | more than 5 years ago | (#26323893)

From a coding/QA standpoint, one has to wonder how this bug was missed if the quality assurance team wasn't slacking off.

MSFT's QA team hasn't been slacking off. They haven't slacked on since about the mid 90s.

Re:QA team slacking off... (1)

KiltedKnight (171132) | more than 5 years ago | (#26324071)

You proceed from a false assumption... that Microsoft ever really had a QA team in the first place.

Re:QA team slacking off... (0)

Anonymous Coward | more than 5 years ago | (#26324141)

My first reaction from looking at the code is that it's the development (coding) team's responsibility to test for these type of bugs, more so than QA.

But the bug is in Freescale's driver, so the lines of responsibility become blurred. Freescale's coders should have caught that bug in unit testing, but MS should've had controls in place too.

Microsoft is just misunderstood, that's all. (0)

Anonymous Coward | more than 5 years ago | (#26324243)

It's annoying, but people keep thinking of Microsoft as a mediocre computer company that is sometimes abusive. But it isn't. Microsoft is a perfect abuse company that uses computer software and hardware to deliver abuse.

Just my opinion, but I'm not the only one.

QA?? (2, Interesting)

Gorimek (61128) | more than 5 years ago | (#26323919)

This kind of bug is where TDD shines. If you don't write any code unless you have a test that forces you to, it's very hard to produce this bug type.

(TDD = Test Driven Development [wikipedia.org] )

Re:QA?? (0)

Anonymous Coward | more than 5 years ago | (#26324027)

That's an unrealistic and naive approach to development. Bugs happen, regardless of the methodologies put into place.

The larger the project, the more limiting and unrealistic TDD becomes. How's a project with a couple of million lines of code supposed to be put through TDD? It won't.

Re:QA?? (0)

Anonymous Coward | more than 5 years ago | (#26324161)

Not really. The bug is a simple algothrimical problem, if you're writing an algoritm you should be able to prove it's functionality by writing some fairly straightforward unit tests

Re:QA?? (0)

Anonymous Coward | more than 5 years ago | (#26324187)

Test Driven Development assumes it's possible to write a test for every possible condition. That is flat out impossible because as a project grows in size the test tree grows exponentially. Eventually it becomes like trying to test for every possible move in Chess or Go expect multiplied many times.

Currently proper TDD just impossible even if it were possible to make an automated system, let alone doing it "by hand" with code monkeys writing tests.

Re:QA?? (0)

Anonymous Coward | more than 5 years ago | (#26324303)

Nobody, but nobody is claiming that TDD catches every single possible bug. But done properly [amazon.com] , it's extremely useful, and it does a great job of preventing regressions.

Re:QA?? (1)

thermian (1267986) | more than 5 years ago | (#26324305)

While it is possible to test what you might term 'worker' methods that manipulate data in easy to test terms, like adding, deleting, transforming and such, its really quite hard to use TDD when developing software for whom neither the exact, nor even the ideal outcome is known in advance.

I speak of things like GAs and such. Sooner or later there will be a need for large blocks of very complex code which can't easily be broken up so you can run a test and say 'that' bit is broken.

I use unit for some things, but I would not consider using it for an entire application unless that application were really simple.

Re:QA?? (0)

Anonymous Coward | more than 5 years ago | (#26324343)

Suppose Freescale and/or Microsoft had used TDD for this particular piece of code. To avoid falling in the trap of using the same algorithm to test the module being tested, they probably would have written the unit test to check that the correct result was obtained for an array of specific dates (let's say 30), including leap year dates such 29-Feb-2008 and 4-July-2004 and "boundary cases" like 1-Jan-1980, 31-Dec-2010, etc.

TDD would only have caught this if the developer had had the foresight to include 31-Dec-2008 in the test.

Bigger bugs have gotten through on Windows CE (5, Interesting)

msgmonkey (599753) | more than 5 years ago | (#26323935)

For example I had some code I developed on Windows CE 4.2 .NET which kept on hanging on calling the FindWindow() fuction call.

Turns out that trying to find a window by class name will hang (this version of) CE every time, even though you would have thought its a very much used function call and would be caught by CE.

So no I'm not surprised at all that this bug got through.

Re:Bigger bugs have gotten through on Windows CE (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26324075)

If you dealt with Platform Builder you could see the WindowsCE source code. There were some amazing bugs in there. One that is more relevant that i saw in WindowsCE 4.x was the daylight savings changeover code.

They had a function that returned whether or not time needed to be added for daylight savings. The function would have a list of changeover times for various regions. If the time was past the first changeover time of the year the function would add time, if the function was past the second changeover time in the year the function would remove time.

The end result was the product shipped with time that was incorrect for the entire Southern Hemisphere.

Re:Bigger bugs have gotten through on Windows CE (0)

Anonymous Coward | more than 5 years ago | (#26324085)

This bug still exists in CE 5. I've encountered it on Windows Mobile 5 and 6 devices. Based on my experience writing apps for these devices, the whole CE/WinMo QA group should be the first to go in the upcoming round of Microsoft layoffs.

That code is real bad code! (2, Insightful)

canuck57 (662392) | more than 5 years ago | (#26323969)

Looking at that code, it never had effective code review or Q/A. If I was the manager responsible I would be looking up those who signed off on the code in the last review. I didn't spot one, but 4 issues in that code and would not doubt more exist. Second off, there are much simpler ways of doing this in the C libraries, and simplicty has value.

But the design, I suspect is very flawed. Why not use asctime() and rely on it's more proven calculations of leap year and the like via the OS libraries?

And when you see something like this, you know someones brain was in the off position:

556 day -= 366;
557 year += 1;

Re:That code is real bad code! (1)

colfer (619105) | more than 5 years ago | (#26324221)

Those lines are correct. The function takes days=number of days since 1980, and calculates year/month/day, as well as the day of the week.

Re:That code is real bad code! (1)

cbhacking (979169) | more than 5 years ago | (#26324345)

Why do those particular lines strike you as so especially terrible? It's part of an iterative function that takes a number of days since a defined starting point (Jan 1 1980, inclusive, IIRC) and determines how many years (and the remainder number of days) have elapsed. The comments made that fairly clear to me.

Re:That code is real bad code! (0)

Anonymous Coward | more than 5 years ago | (#26324361)

Because this code is _in_the_os_, it was provided by the CPU manufacturer for an embedded component. If anyone tried to put a call to asctime in this code, I would have them hung drawn and quartered because it would have killed performance.

Damn, performing string operations in driver code on an mp3 player.

Even worse, assuming that the C library is present and conforming.

wow, just wow.

Regardless of whatever code in it is faulty (5, Funny)

scourfish (573542) | more than 5 years ago | (#26323979)

Lines 122, 521, 690, 710, and 748 scare me; gotos in C code...

Re:Regardless of whatever code in it is faulty (3, Insightful)

KiltedKnight (171132) | more than 5 years ago | (#26324061)

Ever written code for an OS or device driver? You use them there... frequently... as "get me the frack out of here because of a fatal error"...

Never mind that if done properly, there is nothing wrong with using a goto statement... just make sure that you only move in one direction... ideally "down" towards the end of the function, not somewhere else in the whole program.

Re:Regardless of whatever code in it is faulty (5, Interesting)

concernedadmin (1054160) | more than 5 years ago | (#26324089)

Lines 122, 521, 690, 710, and 748 scare me; gotos in C code...

They've used one form of a goto that's actually quite readable and useful. Would you rather have:

if (condition1 && condition2) {
/* boilerplate code with a return */
}

if (issue1 || issue2) {
/* same repeated boilerplate code with a return */
}

or

if (condition1 && condition2) {
goto cleanup;
}

if (issue1 || issue2) {
goto cleanup;
}
cleanup:
/* just one instance of this code,
no need for duplication of efforts */
Believe it or not, there are useful reasons to use goto, and Microsoft happened to use goto for the right reason here. The Linux kernel also happens to use this practice to boost the readability of the code.

Re:Regardless of whatever code in it is faulty (2, Insightful)

jd142 (129673) | more than 5 years ago | (#26324219)

Why not this:

function cleanup():void
{ //do something
}

if (condition1 && condition2) {
cleanup();
}

if (issue1 || issue2) {
cleanup();
}

If something is done exactly the same way twice, that's a function. Heck, if something is sufficiently complicated that it makes the main code easier to read, that's a function too in my book.

Of course, I prefer my braces to line up vertically, so what do I know?

Re:Regardless of whatever code in it is faulty (0)

Anonymous Coward | more than 5 years ago | (#26324327)

What do you do if you have 10 variables allocated locally in the function? Pass them all to the cleanup function?

Re:Regardless of whatever code in it is faulty (4, Informative)

AuMatar (183847) | more than 5 years ago | (#26324367)

Because cleanup doesn't have access to the local variables of the calling function. This means they need to be passed in. The result is a very obscure function that takes in half a dozen or more variables and gets difficult to maintain since it's purpose makes absolutely no sense without the context in the calling function (not to mention easy to have bugs- forget to check just one pointer for null before using it and you're into undefined behavior, which may only occur in rare error conditions making it difficult to test for). Using a cleanup function like that just isn't practical.

Re:Regardless of whatever code in it is faulty (1)

cbhacking (979169) | more than 5 years ago | (#26324395)

Mostly that's a matter of the way cleanup frequently involves local variables. Sure, you could pass them all in by reference (since this is C, that would mean passing them as
cleanup(&local1, &local2 &local3);
but it gets quite messy, both in the function declaration and in all the calls.

Re:Regardless of whatever code in it is faulty (0)

Anonymous Coward | more than 5 years ago | (#26324289)

Sheesh, a long time ago someone noticed all the crappy code being written with goto and globals (or whatever) and wrote a paper about it. Now every moron developer thinks it's always bad to use them in every case. I see people (especially younger developers) with this attitude all the time. They see some code and freak out about how bad it is and how the programmer didn't know what they were doing because it has a global variable or something. It's funny because they are the one that is clueless.

They can be used effectively and are often required for a good proper design. A skilled programmer would recognize this.

Sad code, sad article (3, Interesting)

gnasher719 (869701) | more than 5 years ago | (#26323995)

Both the original code and the various corrections in the article don't catch what the algorithm is supposed to do, and therefore create code that is too complicated.

The essence of the algorithm is this: We start with number of days since 1/Jan/1980, with the first day having the number one. We want to end up with the correct year, with a day number relative to the first day of that year, with the first day again having the number one. So we set year = 1980. And as long as day is greater than the number of days in that year, we can't have the right value yet, so we change day and year accordingly. This produces a very simple loop:

for (;;) {
    int daysInYear = IsLeapYear (year) ? 366 : 365;
    if (day = daysInYear) break;
    day -= daysInYear; year += 1;
}

This is what Knuth called an "N + 1/2" loop: A loop pattern where a more or less substantial bit of code has to be executed at the beginning of the loop before we can decide whether the loop needs exiting or continuing. By following the "N+1/2 loop" pattern we avoid repeating the same code (with possible small changes) completely. And that exactly was the problem here: The same code was used twice but slightly differently (one set number of days = 365, the other made it dependent on whether the year was a leap year or not). The solutions given in the article all contain repeated code; either two loop exits, or a duplicated calculation of the number of days in a year.

Re:Sad code, sad article (5, Informative)

chalkyj (927554) | more than 5 years ago | (#26324145)

I think slashdot ate your < in the breaking line.

Re:Sad code, sad article (5, Funny)

xlv (125699) | more than 5 years ago | (#26324157)

for (;;) {
        int daysInYear = IsLeapYear (year) ? 366 : 365;
        if (day = daysInYear) break;
        day -= daysInYear; year += 1;
}

This is what Knuth called an "N + 1/2" loop

No, this is what Knuth would call an infinite loop as there's no way to terminate the loop except on the last day of each year...

Re:Sad code, sad article (1)

xlv (125699) | more than 5 years ago | (#26324377)

or at least it would be if it was "==" instead of "=" so next time I should double check before pointing problems in somebody else's code...

In any case, as others have posted, the loop termination is not correctly implemented but pointing out the weird termination because of a missing '<' is not as funny.

Re:Sad code, sad article (0)

Anonymous Coward | more than 5 years ago | (#26324199)

The worst part of that sort of problem is that as time goes on it takes longer and longer to execute. Not much but is gets slower by little bits each year. Blech...

Then if you call it a lot it gets geometrically worse.

That this sort of code exists in CE I am not surprised. The build system is one giant nightmare of batch files built ontop of visual studio 5/6. It is a very fragile system.

Also many times the drivers and code is not even written by MS itself. It comes in from their 3rd parties with very little review or vetting.

If you decide to use CE in your system. Heed my words bash every function and as many permutations of calls as you can and drop it right back in MS's lap. The thing really starts to fly apart when you try to actually multitask in any meaningful manner. It is a 'task pad' OS that has been bent and twisted into a 'embedded system' OS. That it breaks in weird bad ways does not surprise me. Win9x was better written...

Re:Sad code, sad article (1)

colfer (619105) | more than 5 years ago | (#26324253)

In your break line, '=' should be ''.

Re:Sad code, sad article (1)

colfer (619105) | more than 5 years ago | (#26324279)

Ack! Yeah, it's that html thing... preview is such a speedbump...

Re:Sad code, sad article (1)

davepermen (998198) | more than 5 years ago | (#26324277)

shouldn't it be if(day = daysInYear) or so? (or even just ) but in essence, your idea is correct and the code is much more auto-proven to be correct or wrong, as it's much simpler to understand.

Re:Sad code, sad article (1)

davepermen (998198) | more than 5 years ago | (#26324331)

.. html bug.. if(day <= daysInYear) or if(day < daysInYear) even.

Modified Julian Day (1)

janwedekind (778872) | more than 5 years ago | (#26323999)

Software for time computations should use the *Modified Julian Day* [1] which provides a continuous time measure. You can find implementations of the conversion algorithms in astronomy software (including even the Gregorian calendar reform for those really old music files).
[1] http://en.wikipedia.org/wiki/Julian_day [wikipedia.org]
[2] http://en.wikipedia.org/wiki/Gregorian_calendar [wikipedia.org]

Re:Modified Julian Day (4, Funny)

rcw-home (122017) | more than 5 years ago | (#26324229)

I highly recommend that in cases like this, programmers be good Catholics and abide by the decree of Pope Gregory XIII. Software written to work with modern dates should use Gregorian, not Julian. Or did you mean ordinal?

From the article you linked to: The use of Julian date to refer to the day-of-year (ordinal date) is usually considered to be incorrect, however it is widely used that way in the earth sciences and computer programming.

Re:Modified Julian Day (1)

plopez (54068) | more than 5 years ago | (#26324295)

Most people mean DOY when they say Julian.

Re:Modified Julian Day (1)

rcw-home (122017) | more than 5 years ago | (#26324387)

And maybe after society rebuilds itself from global catastrophe, and all memory of the Roman Empire or the frickin' month of July have been long forgotten, they'll be right.

No problem since 1966 in FORTRAN (2, Informative)

slugmass (1215630) | more than 5 years ago | (#26324011)

integer function f_isleap(year)
            IMPLICIT NONE
c
c Purpose :: Return 0 if a year is NOT leap year and a 1 otherwise.
c
c Description: Every fourth year is a leap year. c But NOT when divisible
c by 100, except if the year is divisible by 400.
c
            integer Year
            if((MOD(Year,400).eq.0) .or.
          % ((MOD(Year,4).eq.0) .and.
                    (MOD(Year,100).ne.0))) then
                  f_isleap=1
            else
                  f_isleap=0
            endif
            return
            end

But of course FORTRAN is not fancy enough for super cool C# coders.

Re:No problem since 1966 in FORTRAN (1, Funny)

Anonymous Coward | more than 5 years ago | (#26324111)

Lovely. The coder who admonishes other for not using FORTRAN presents a solution for the wrong problem. How do you shoot yourself in the foot with FORTRAN?

Re:No problem since 1966 in FORTRAN (1)

Guy Harris (3803) | more than 5 years ago | (#26324121)

The problem wasn't with the code that determined whether a year is a leap year or not (which was correct, and was using the same algorithm as your FORTRAN example). The problem was with the loop, and somebody could've made the same error in FORTRAN 66.

Probably Not A Widespread Issue (5, Informative)

nato10 (600871) | more than 5 years ago | (#26324051)

This code is actually from the Windows CE OAL (OEM Abstraction Layer), part of the code that reads the current time from the RTC. As such, the implementation is hardware-dependent, which is why there isn't a standard implementation of this function for Windows CE.

In addition, this code is in a portion of Windows CE source code provided by a device's BSP developer, not by Microsoft. In most cases, Windows CE BSP developers start with sample BSPs written by a processor's manufacturer -- in this case, Freescale -- and then improve it.

It turns out that this bug is specific to the Freescale's BSP -- sample Windows CE BSPs for other procesors don't have it -- and other Freescale devices using Windows CE will only have this issue if their developers used this code verbatim. Since sample BSPs provided by processor manufacturers are often of poor quality, many Windows CE developers typically rewrite such functions. In other words, the impact of this particular bug may be quite limited, which may be why there haven't been reports of this issue on other devices.

In this particular case, though, Microsoft (or a contractor) was the Zune's BSP developer, so they certainly should have caught this.

Re:Probably Not A Widespread Issue (3, Funny)

TheSunborn (68004) | more than 5 years ago | (#26324203)

I still wonder: Why is code that translate from a number of days, to a year hardware dependent?

Getting the number of seconds since epos is hardware depending, but translating this to other time measurements should not be,
unless they are building a time machine.

----====**NEWSFLASH**====---- (-1, Troll)

MrKaos (858439) | more than 5 years ago | (#26324143)

A Microsoft product has bug in it!!!!

Oh, the humanity.

Talked-about layoffs at MSFT (0, Troll)

postmortem (906676) | more than 5 years ago | (#26324167)

This is what happens when there are no serious consequences for the bad work.

They seriously need to lay off the bottom 10% (or 20?) of their workforce for the first time in company lifetime. Some people ought to be scared of bad work they do. There's no way for any company that all 100% of workforce are productive and useful.
I bet remaining workforce and end-users would thank them.

exact (0, Flamebait)

binaryseraph (955557) | more than 5 years ago | (#26324179)

I think the exact cause can be summed up as this: It's Microsoft.

When did the bug happen? (1)

jrumney (197329) | more than 5 years ago | (#26324185)

I've seen reports of the bug happening on 1 Jan, and the summary seems to say that too. But shouldn't the bug have happened on the 31 December, the 366th day of 2008?

Not so uncommon (2, Interesting)

fermion (181285) | more than 5 years ago | (#26324265)

These functions that are only used once in great while are the devil to test. I think anyone who has programmed in any complex situation will have to admit to one of these silly bugs, and maybe even the bug going to production.

What I see here is a really convoluted piece of code to perform a really simple task. There are a lot of constants that are written as constants. If there a #define orginyear, the why not #define daysperyear and #define daysperleapyear. The first is used only once, while the rest are used twice.

In any case, the fundamental problem is not encapsulating data. This is quite a common error is code architecture. In this case, this function knows a lot of things it does not need to know. It know about leap years, number of days, and all this confuses the reader. They layout of the function already has the overhead of a fuction call, so why do we not let this overhead work for us by not returning the proxy leap year boolean, but what we actually want, which is the number of days in this year.

int daysperyear;
for(;;)
{
daysperyear=howmaydaysthisyear(year);
if(days>daysperyear)
{
days -= daysperyear;
year++;
}
else
{
break;
}
};

In this case all days per year information and leap year information is encapsulated in a single function, and the top function does not need to know about either. This, I think, is writing quality into code, and not depending on QA to catch mistakes common to novice programmers. No guarantee this will work as is, it is just psuedo code, not even checking the logic completely.

We don't have time for QA (1)

plopez (54068) | more than 5 years ago | (#26324267)

That's the mindset of most software developers and managers. And when it is done, it is done incorrectly, tacked on at the end as if you are testing a dishwasher.

QA/QC (there is no uniform definition of the two) pays off if you build it into every step of development from day one and follow through. Unit testing is a part of it (and is a great idea, it really helped me), but only a part.

Read Demming.

The whole industrial is bad (0)

kentsin (225902) | more than 5 years ago | (#26324383)

The whole I.T. industrial is modeling. The computing world is a model of the real world. One can not map the whole world in their computer world, that some kinds of simplification is needed.

How much detail is enough? No body ever answer that, and no one care.

Y2K is just Y2K. how long does a time representation is enough? How big should the address pointer?

Is anybody care about that? The whole industrial is based on assumption: this is enough and it turn out the actual answer is NO.

Starting from the beginning of our education, we demonistration all such unthinking simplification of the representation of the real world. And the whole industrial does not take a second through of how these simplification were causing us.

Every people write system requirement just boost their specification from time to time. No body really get those cut-off points into the specification. No efforts ever put to identification where we have made a simplification which may cause our arms or legs when time come.

The whole computing education and education should rethink this modeling issue.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>