Zune software bug

I would like to know how this sharing is any different than the basic Windows media sharing. Of course, fixing the software is far more important than answer one little question. Sorry, we can't find the page you're looking for. It might have been removed, its address might have changed, it might be temporarily inaccessible, or you might have mistyped the address.

Was this reply helpful? Yes No. Sorry this didn't help. What kind of short sighted development is that? And how does any software engineering team working on a internal clock not include leap year into their calculations??

This bug could have been caught and eradicated if the software went through a peer review. But even a peer review can fail if you don't have the knowledgeable and experienced programmers on the team in order to help catch errors or discover overlooked industry conventions. So I also emphasize to my students the heuristic: variations among people account for the biggest differences in software productivity.

So always try to hire good people. Video Bootcamp. Free Stuff. Success Stories. Who we are. How it Works. First-generation Zunes—those with gigabyte disk drives—went silent everywhere on December The bug is an interesting one, if only because all the details, including the source code, immediately came to light.

A copy of the C source module which bears copyright notices from both Microsoft and Freescale Semiconductor was posted here.

And I do think this is an error that should have been caught in testing or during a code review. And I think the main lesson from this incident is not the usual refrain that Microsoft is lame. Subtle traps lie in wait even in what seems a very simple algorithm. The purpose of this routine is to calculate the current year.

On entry, the variable days is equal to the number of days since January 1, , which is taken as the beginning of time. On exit, the variable year is supposed to hold the correct year number. The IsLeapYear predicate does just what you would guess. At the end of the process, the year count should have reached the correct current value.

Can you spot the problem? Consider what happens when the initial value of days is Since this number is greater than , we pass the test at the head of the while loop and enter that block. Since the initial year is , the IsLeapYear predicate returns true , and we enter the consequent clause. We simply return to the head of the while loop, where we find that days is still greater than , and so we go through the same motions again, and again, ad infinitum.

This is just what happened on December 31, , which was day 10, in Zune time. A reader at Zuneboards. As another reader pointed out, this is incorrect. The change eliminates the infinite loop, but the altered routine returns the wrong year on December 31 of every leap year. The reader who spotted this error suggested a different solution, adding an else clause with a break command:. As far as I can tell from running a few test cases, both of these versions yield correct results, but their logic is anything but perspicuous.

Trying to verify correctness by ure reason—as opposed to trial-and-error testing—looks almost hopeless. Or so I thought. This violates an implicit assumption that year will always be equal to or greater than In some programming environments, we could even make that assumption into an enforceable assertion, in which case this code would break. And both of these routines can leave the variable days with a negative value, which is also nonsensical.

So I put the question: Is there a better way? Can anyone come up with the One True Algorithm for calculating years from elapsed days? Is the first day of January in to be interpreted as day 0 or as day 1? Nothing I could find in the original code resolves this ambiguity. When I first looked into the matter, I guessed that counting began with day 0 because the Zune routine correctly returns year for day values from 0 through But if the zero-based assumption were correct, the Zunes would have died on January 1, not December The code implements the rules of the Gregorian calendar: A year is a leap year if it is divisible by 4, unless it is divisible by but not by So far so good.

Elsewhere in the program, however, we find these declarations:. Thus it turns out the Zune has a fixed lifespan of years, from January 1, , through December 31, Many systems have been designed to work from through precisely in order to take advantage of this shortcut. Or have the authors done the right thing by putting the full logic into the code, just in case someone later decided to extend the MAXYEAR deadline past ?

Plus, you do away with yucky iteration. Why start at , BTW?