« Syntaxhighlighter Hello World!
AT&T “break” bug »

The book “The Practice of Programming – Brian .W.Kernighan and Robert Pike“  is one the books, which has a profound influence on the way I  program/debug. One of the advice it provides is :

Know yourself, and the kind of errors you make.Once you have found and fixed a bug, make sure that you eliminate other bugs that might be similar. Think about what happened so you can avoid making that kind of mistake again.

The book provides the above advice in the context of an implementation of a very useful UNIX utility, strings. One of the  functions in that implementation had 3 erroneous calls to printf . Later, it was fixed in one place, but the other two calls were not fixed.

Now you might be wondering how is this related to the Zune bug. The original file containing the bug is available for public viewing.  The root cause for the bug is also explained in detail in  zuneboards.com forum. Upon a close observation of the file containing the bug, we can  notice that  there is a function MX31GetRealTime, which contains the similar code as in the buggy function, ConvertDays. But MX31GetRealTime has the correct version  with an extra break statement. 


year = ORIGINYEAR;
while (day > 365)
{
if (IsLeapYear(year))
{
numOfLeap++;
if (day > 366)
{
OALMSG(OAL_RTC&&OAL_INFO, (TEXT("Leap Year: %u"),year));
day -= 366;
year += 1;
OALMSG(OAL_RTC&&OAL_INFO, (TEXT(", Days left: %u\r\n"),day));
}
else
{
OALMSG(OAL_ERROR, (TEXT("ERROR calculate day\r\n")));
break;
}
}
else
{
OALMSG(OAL_RTC&&OAL_INFO, (TEXT("Not Leap Year: %u"),year));
day -= 365;
year += 1;
OALMSG(OAL_RTC&&OAL_INFO, (TEXT(", Days left: %u\r\n"),day));
}
}

Probably this bug wouldn’t have been there, if the above advice from the book had been followed!!!

In the next post, I will discuss about an (in)famous AT&T bug, which was caused by the inclusion of break statement (quite the opposite of this case :-) .

This entry was posted by CH Gowri Kumar on January 5, 2009 at 10:43 pm under Uncategorized. You can leave a response, or trackback from your own site. Follow any responses to this entry through the RSS 2.0 feed.

3 Comments

  1. Samuel Tardieu says:

    That would still have been bad coding practice: code duplication (and functionality duplication) must be avoided at all costs. That functionality should have been factored; a template (or even a macro if the language doesn’t support templates) would have been better.

    January 6, 2009, 6:26 pm

  2. AT&T “break” bug | CH Gowri Kumar's blog says:

    [...] « The Practice of Programming advice – Zune bug [...]

    January 6, 2009, 11:51 pm

  3. CH Gowri Kumar says:

    @samuel,
    you are correct, code duplication should be avoided as much as possible. But in this case the code was similar, but not exactly the same. Additional debug statements are present in the MX31GetRealTime.

    And on the note regarding macros being supported, I would prefer inline functions to macros.

    January 7, 2009, 12:12 am

Leave a Reply