The Zune Bug and the if/else Statement
legit | 12 January 2009For those that haven’t heard, the Microsoft Zune’s OS recently ran into trouble relating to 2008 being a leap year. The Operating System got stuck and was unable to operate for an entire day due to a bug in the code, thankfully without a patch the Zune started right back up the next day happy as ever.
Over at “Freedom to Tinker” they wrote up a nice overview of the bug (including code):
On December 31, some models of the Zune, Microsoft’s portable music player, went dark. The devices were unusable until the following day. Failures like this are sometimes caused by complex chains of mishaps, but this particular one is due to a single programming error that is reasonably easy to understand. Let’s take a look.
Here is the offending code…
Read the full post here “Debugging the Zune Blackout“. This particular bug represents the problem of not covering all of the cases involved in a particular if/else; in this case the else was left out. The problem could have been solved by breaking out of the while when it was a leap year but not over 366 days.
This reminded me of the Gaurded Command Language(PDF) written by Dijkstra in 1975 (wikipedia article). In this theoretical language Dijkstra presented the If statement with a unique twist. The if statement consisted of several boolean conditions and their subsequent code to be executed. So for a very simple example:
if
if A then AX
if B then BY
if C then CZ
fi
The twist comes on evaluation of the if statement, unlike most modern languages (I don’t know of any that aren’t like this) in which when none of the statements in an if/else are evaluated to true the program simply continues executing, Dijkstra’s Guarded Command Language was different. Three basic rules existed for the if statement:
1. All of the boolean conditions are evaluated.
2. If one or more are true then one (and only one) is arbitrarily chosen to be executed.
3. If however, none of the boolean conditions are true the program aborts (crashes).
This is certainly much more strict than modern languages, thankfully, but it presents the nice idea that unless all of the cases of a given circumstance are covered then the program will not be capable of continuing. Furthermore by preventing the continuation of the program when no true conditions exist the language makes it easier to debug because the problem does not cascade down into some other section of code but rather crashes exactly where the problem originates (the if).
On a more philosophical level the Guarded Command Language deals with if’s in this way: When a child is asked by their mother if they want an ice cream cone and the mother only expects the answers ‘yes’ or ‘no’ then the mother is ill-equipped to deal with the scenario that the child may say ‘later’. Granted we humans are smart and can on the fly deal with situations like this (ie. the mother wouldn’t “crash”) it presents the problem that when dealing with programming in a highly logical environment the fact that when not all possible answers to a problem exist it means that something is not being dealt with, which can cascade down into other problems.
The Zune bug presents a nice example of this, and while it is fairly small its an interesting and yet important issue involved in programming.





