A lesson on infinite loops

As this bug only occurs on the last day of a leap year, it went by undetected for quite some time. While there are quality assurance engineers whose job it is to look for bugs such as this, given the amount of code involved and possible configurations, it’s hard to test for.

There is a famous problem known as the halting problem which states that you can not create an algorithm which can correctly determine if a program given to it contains an infinite loop (for any such program.) While QA people can certainly write scripts to test code and review it, it is almost inevitable for bugs to exist in a shipped product.

As far as alternate coding styles, different coders will find different methods logical. The cost of a few operations for a processor is nothing compared to the cost of having a bug or having code which others find hard to read down the line.

P.S. If you really are conserved with saving cycles, the top line can be changed to “daysThisYear = 366;” (as 1980 is always the initial year and is a leap year.) That should trim about 2 nanoseconds off of the boot time .

Very true. The alternate strategy would then be to define a constant DAYSINFIRSTYEAR right underneath where ORIGINYEAR is defined with a comment explaining that both must be changed together. However, this is indeed a case where for simplicity’s sake, the best path is probably not to worry about making the very most efficient code possible at the cost of legibility and bugproofing.

Actually the **real** problem is that they don’t separate logic like that into subroutines. This logic is repeated in another routine in the same program; in which it looks like it was actually corrected to include a break statement:

   //Calculate current year, month, and day use the value stored
   //in RTC day counter register
    OALMSG(OAL_RTC&&OAL_INFO, (TEXT("RTCDayCnt=%d\r\n"),day));
    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));
        }
    }

So it’s likely they hit this bug in testing; and corrected it in the one place and not in the other.

comment edited by Bryant: added pre tags to the code sample.

@iamacyborg:

Well, they screwed that up too. They’re putting out an error message whenever it’s the 366th day of the year.

i think your last optimizations are superflous. most compilers (msvs & gcc) already do them automatically (loop conditional unswitching, constant & copy propagation).

int leap = IsLeapYear(year);
while (days > (leap ? 366 : 365))
{ … }

huh?
This “solution” breaks the function. IsLeapYear() has to be called once per pass because it returns a different value depending on what year it is…

Otherwise you’re just going to pass IsLeapYear(1980) each time… Which I’m sure the compiler will happily optimise out entirely for you…

Andrew, check the code again. Look at this line:

daysThisYear = (IsLeapYear(year) ? 366 : 365);

That line checks the newly incremented year (incremented in the line before it) if it’s a leap year and sets daysThisYear accordingly. Example:
-1980 is checked before the loop starts. It’s a leap year, so daysThisYear = 366.
-Loop starts. 366 is subtracted from days.
-year is incremented by 1
-daysThisYear is reevaluated with the new year. 1981 is the new year and is not a leap year. Thus, daysThisYear is now 365 before the loop begins again.

While I agree with Matt Boehm to a certain extent (actually, almost all of it), engineers are trained to test boundary conditions. Which is why I say to Michael Campbell, any test engineer worth their weight should have realized there are 4 particular boundary conditions that should be tested, namely the the first and last days of “normal” years and leap years. Hell, with a testing environment, it doesn’t really cost you much to set it running, testing each and every day from 1 Jan., ORIGINYEAR, on until eternity, while you clock out for the day. Not only are you able to then test 30 day months vs 31 day months, but you get 29 Feb and 31 Dec leap year for free. In this case, you come back to your computer and you see it’s stuck in an infinite loop, and since it’s in a testing environment, (you did use a testing environment, right?) you know that it’s the 31 Dec on a leap year, or, if you’re lucky, your testing environment has detected that each 31 Dec is (likely) an infinite loop and continued on testing the next 4 years without problems.

> Only if one was smart enough to include this edge case test.

In a TDD environment it’s not that the developer would have to remember to test this case, it’s that he wouldn’t have added the code for this case without first having written a test which failed. Test _first_, implementation _second_.

@Brandon:

The reason is that the Zune stores the days since epoch (in this case, 1 Jan 1980) as an integer. That means that 1 Feb 1982 would be 31+1+366+365=day 763 for the Zune. Using an if instead of the while, it would think that it’s always 1981 for every day after 31 Dec 1980, which for 366 days in all of eternity, would be fine, and then for another 59 days but shifted 2 days of the week, but for every other day (infinity vs 425), it would be screwed up immensely.

If you are really concerned about efficiency, you can actually get rid of the loop altogether and replace it with a couple of expressions involving modules and divisions. As for optimizing away the first call to IsLeapYear, well, replicing this funcion with a one-line macro or inline function should be enough to get the compiler to do it for you.

In 2008, this iterates through 28 cycles every time it’s called. Why didn’t they compute a table of, say, 50 base years from 2000 to 2050 and use bsearch to find the answer? Also, IsLeapYear should start with if (Year & 1) return 0;

Who wrote this lousy code?

@Jonathon: Yeah, I agree with you there: of course, who would expect any of these types of devices to last 50 years?! But 50 years x 365.26 days/yr is going to add up to a lot of memory: 18263 distinct values, which if you use SHORT’s to represent the days, still is over 35K of memory for this. It’d be better to use a function.

The above example is why crusty old embedded systems programmers are wary about while loops.

IHO the code below is more straightforward.

while (1) // forever!
{
if(IsLeapYear(year))
{
if(days <= 366)
break; // exit stage left

days -= 366;
}
else
{
if(days <= 365)
break; // exit stage right

days -= 365;
}
year += 1;
}

or even better.

while(1)
{
if(IsLeapYear(year))
daysinyear = 366;
else
daysinyear = 365;

if(days <= daysinyear)
break;

days -= daysinyear;
year++;
}

Both are less confusing and easier to follow. The second case probably would be less likely to be ‘corrected’ by a multiple exit hate’n weenie.

This such a 80’s issue. Why is code still being written to do a simple function poorly.

First mistake is choosing 1980 as a start year, instead of 1981. It is simpler to convert from date to days and back when the base is on a start of a leap cycle. Then simple 28.25 days for February, or 365.25 for year would work. Also it is better to only use 1 count of days (31, 28.25, 31.. vs 365.25) since it is easy to make mistakes.

Oh, when I write 28.25, a really mean 2825 in a UINT. This 100 times to big so final answer is always / 100.

No, no, no! You musn’t give code to Microsoft!

Remember that OpenSource is the scourge- let them pay to figure out their problems. More people today have seen code than at Microsoft all year, I’ll bet- and not one of them was paid. Charge them millions for this fix…”it’s what the customers want!” :>

Let’s not run to the rescue with solutions- not for free, anyway. Free solutions “can’t be any good” and “who would provide programming for free?”.

:>

@Sineibe, check that code snippet again. The same line is called once inside the loop as well.

@crash

multiplication and division are expensive operations. I don’t know if the loop is more or less expensive overall though. Also I don’t think the floor is necessary since integer division would be used anyway.

Umm… While the Extra Credit optimization is valid, each of the three below it is not. Each of them evaluates “year” outside the loop, then increments it inside. In the first version, while we do call IsLeapYear(year) repeatedly, with the exception of the first pass through the loop, each time we call it, we have a new value of “year” to check. In each of the others, we have a stale value of IsLeapYear(year).

It is faulty optimizations like this that cause this sort of problem. Be not so proud of thine coding expertise, youngling.

Charles W, don’t fret. Andrew and Sineibe missed it as well, so you’re hardly alone.

Crash, read the wiki on leap years: http://en.wikipedia.org/wiki/Leap_year
Because the there are not “exactly” 365.25 days in a year (which would benefit the year % 4 concept only), then there are exceptions. Every 4th year, except every 100, except every 400, except…. (TBD). The number of days in a year are (to the best of human knowledge), 365.24219, 365.2424, or 365.2425… and all of these are averages. Also, the number of floating point days per year in increasing each year. So, these are only current day rules. Who knows what the future will bring. If only the universe were a digital one.
For fun, read the wiki on leap seconds. Try getting your mind around that one. The super-big science guys just added one this new year’s eve. Did you feel the hiccup in the space-time continuum?

@Nobody: Thanks for turning my world inside-out. I had heard about the leap second thing recently but I wasn’t aware of leap years being so ridiculous. I tip my hat and call it a day. Let somebody else figure out pi — i mean leap years.

@Crash.. sorry ’bout that. Happy New not-a-leap-Year! I was working on a time calculator/converter a few years ago when leap seconds sank my boat. I’ve come to realize that it’s these digital-meets-analog encounters that keep everything so interesting.

@dlesko

Okay, wow. I didn’t think of that at all. Well done.

@Super Francis: I was simply trying provide an explanation of how such a bug could slip by undetected for years after launch if not caught early on while programming. I’m by no means trying to act as an apologist for Freescale. I was mentioning this in the context of Microsoft coming under fire for a bug in a third party driver. Any programmer worth half his salt knows to test his code as he’s writing it and not leave bugs for QA people to catch (or not, in this case.) I’m agreeing with you that this is the result of careless programming. Sorry to have mis-communicated my meaning to you.

instead of “int daysThisYear = (IsLeapYear(year) ? 366 : 365);”, which I can only assume requires a compare why don’t you just write:
int daysThisYear = 365 + IsLeapYear(year);
More efficient and easier to read (until somebody decides to do something dumb to the IsLeapYear function).

There’s a lot of talk about what the *real* problem is. Well, the *REAL* problem is that someone wrote a function to calculate the number of days since a fixed date, and wrote this function from scratch instead of using an existing function that has been tested for DECADES.

Or rather their converting a number of days to years, but either way…

@Bryant

int daysThisYear = 365 + !!IsLeapYear(year);

The ol’ double not should do the trick. Anything nonzero becomes a 1. I think it can be reasonably assumed that the function returns 0 if it is not a leap year, and some nonzero value if it is. Otherwise, it breaks any possible testing conditions you could apply to it.

int daysThisYear = 365 + IsLeapYear(year);

Is bad programming practice and could easily get you screwed.

IsLeapYear() is defined as returning a bool, which in C is 0 or non-zero.
IsLeapYear() could easily return something other than 1 for true (Often I have seen -1; all bits set in bool results) which would really screw with you.

The other point is that bools are not integers and should not be used in arithmetic. With C you will get away with this
most of the time but then you have to trust a) the developer of the function and b) the compiler/library platform you’re
compiling on (things often vary).

A library developer on some random platform might use the inverted last result of a modulus as a return value for example: this would
reduce his code and be a valid return value for the bool result. Problem then is people using that bool in arithmetic would see 0, -1, -2 & -3
as the return values (depending on the CPU architecture).

@iamacyborg

That is a good point. It would reduce redundant coding if they put that loop into its own function.

It’s unfortunate that someone decided to invent their own routines to do this. Frameworks like .NET, Java, ICU and JodaTime don’t use loops to do this type of Gregorian time calculation. O(constant) will be faster than O(n), especially after a few years. Also those frameworks are much more thoroughly tested and used much more widely.

Guys, guys! You are all missing the point. This was never a bug to begin with. I have it on good authority that the developer was told that the Zune 30 would not be used after Dec 31, 2008.

On a more serious note, it is apparent to me that the Zune 80 and 120 had the fix already or the issue would have occurred on them as well. They use the same processor (the Zune 30 processor is actually 125Mhz faster than the 80/120). Since the hardware is essentially the same with only minor tweaks to increase battery performance it is safe to assume that the firmware is based on the same code. If it was based on the same code then the bug was fixed in the 80/120. Soooooo what we have here is poor internal communication at MS and a general lack of concern for the consumers. Which is why I have an iPod.

The leapyear check is a one-liner, fercryinoutloud. Here it is…

LEAP = SIGN(MOD(IYEAR / ( 100 – 99 * SIGN(MOD(IYEAR, 100), 4)))) will return 0 for leap years, and 1 for non-leap years.

Not tested, but here’s the logic, from the innermost numbers out

MOD(IYEAR, 100) will be zero for a century year (integer divisible by 100) or a positive number for a non-century year

SIGN(MOD(IYEAR, 100)) will be zero for a century year (integer divisible by 100) or 1 for a non-century year

100 – 99 * SIGN(MOD(IYEAR, 100)) will be 100 for a century year (integer divisible by 100) or 1 for a non-century year

If the year is a century year, you’re dividing by 100 first, otherwise take the year as is.

MOD(IYEAR / ( 100 – 99 * SIGN(MOD(IYEAR, 100), 4))) takes MOD 4 of the year (or YEAR / 100 for a century year). This implements the rule of divide by 4 if not a century year, or 400 if a century year.

The outermost SIGN forces any positive MOD result to 1, and 0 stays as 0. Easy, isn’t it? And now for some computer humour…
(read . (my . (lisp . (no . (new. (taxes))))))

@Tim:

No! Code for readability last, or not at all. You should endeavor to write your code such that someone trying to modify it needs to be at least as clever as you are in order to understand it. Otherwise, you end up with some dope down the line who makes what he thinks is an innocuous change that really ends up sending the program into an infinite loop in some quite foreseeable set of circumstances. Ideally, if your code is modified by someone who has no idea what he is doing, it should completely fail to compile. Barring that, it should immediately segfault, spit out screenfull upon screenfull of garbage data, or just terminate silently with no error message. Particularly vindictive coders will cause it to overwrite a database or two, as punishment for trying out modifications on a production system.

@Bryant:

Good thing I’m not in IT, eh?

That was intended as tongue in cheek, actually. But I still stand by my double not as a way of filtering the return value. It’s either a good way of making sure that the value is always something you expect, or a good explanation why you should never try adding a true/false return value to an integer in the first place–I’ll let the reader decide which.

@CJ
The offending code was from a device driver for a RTC. I think the reason why only Zune 30’s were affected by this bug is because the other models did not use that particular piece of hardware. So the small differences between hardware that are essentially the same made all the difference in this instance.

Simple 1-line fix:

365)

> while( days>366 || ( days>365 && ! IsLeapYear(year) ) )

this gives some efficiency — The leapyear test is only done on one day of the year (and only on non-leapyears) and, even then, only on the last iteration of the loop. It also avoids the break statements (which many programmers reserve for emergency uses only).

Your last change (the DaysThisYear) will result in bad counts for leap years.

From a QA perspective, the outrage is that the original loop clearly lacks a variant. A variant is a variable (or abstract expression) which progresses relentlessly toward a fixed termination condition. The variant must progress on *every* iteration. Days is the only variable in the predicate here, so clearly any iteration of the loop in which days fails to decrease is a huge problem.

The other glaring defect is failure to comment the post-condition which appears to be that 0 < days && days <= days_in_year (year). What happens if days is passed into this function as 0? Does the day of week calculation get screwed up later? Day of year is one origin, but the month_tab is zero origin?

I took one look at this and said to myself “where’s the variant?” without even beginning to think about the math or the logic. Termination and correctness are distinct concerns.

No form of this loop should allow a modification to days in a guarded (aka conditional) expression. Days must decrement on *every* iteration, and rightfully this should be an unconditional statement toward the end of the loop body. Until the form of the predicate is changed, any other objection is thinking too hard.

The funny thing is, if you insist that junior programmers define their pre-conditions, post-conditions, and variants, they become motivated to discover that well-tested code already exists.

Check out the article “The Cruelty of Really Teaching Computer Science” on Wikipedia. It doesn’t need to be that extreme, but if you ignore it completely, this is the mess that results.

Douglas Goodall I would be interested to know what other software engineers think about code that modifies stack frame parameters. It seems like something that violates our basic coding rules in c/c++. Am I incorrect? Is this considered all right these days. I am shocked, but if I am wrong I want to know…

I don’t really care about modifying stack frame parameters. Though I tend to avoid doing it as it’s useful to have the original parameter around when debugging. As for it causing unwanted side effects? No, anything passed by value’s scope in C is confined to the function.

Really though the actual problem here is historical, which is traditionally RTC chips keep time in MM:DD:YY HH:MM:SS. A better way of handling this is for the clock chip to keep time in seconds since whenever and let the well tested operating system routines handle conversion to monkey time.

There appears to be a certain amount of muscle flexing regarding how to “best” or most efficiently implement the algorithm. Here’s what I’ve come up with in a few hours. It has advantages (shockingly efficient, no lookup tables, no loops) and disadvantages (unaddressed Y2100 bug).

The key is to make Feb 29th the last day of a repeating 1461 day cycle by resetting the origin from 1/1/1980 to 3/1/1976 and to proceed from there …

#include
main()
{
int i;

for (i=1; i<43892; i++)

{
printf (”%6.6d “, i);
dateconv(i);
}
}

int dateconv(int days)
{
int year, month;

days += 1400; // Reset origin to 3/1/1976

year = days / 1461; // Factor out 4 year cycles
days = days % 1461;

// Compute days into the current year and adjust year

year = year * 4;
if (days < 365) { year += 1976; } else
if (days < 730) { year += 1977; days -= 365; } else
if (days < 1095) { year += 1978; days -= 730; } else
{ year += 1979; days -= 1095; }

// Compute the month and day, adjust year for Jan/Feb
// Also change day origin from 0 to 1 by adding 1 to days.

if (days < 31) {month = 3; days++; } else
if (days < 61) {month = 4; days -= 30; } else
if (days < 92) {month = 5; days -= 60; } else
if (days < 122) {month = 6; days -= 91; } else
if (days < 153) {month = 7; days -= 121; } else
if (days < 184) {month = 8; days -= 152; } else
if (days < 214) {month = 9; days -= 183; } else
if (days < 245) {month = 10; days -= 213; } else
if (days < 275) {month = 11; days -= 244; } else
if (days < 306) {month = 12; days -= 274; } else
if (days < 337) {month = 1; days -= 305; year++;} else
{month = 2; days -= 336; year++;}

printf (”%2.2d/%2.2d/%4.4d\n”, month, days, year);
}

Note that on certain machine architectures, a single divide instruction can produce both the quotient and remainder, which could be exploited by an assembler version of the above algorithm.

The best code :

while((days – (isLeapYear(year) ? 366 : 365)) > 0)
{
years ++;
}

you can test the code above, it would work well!

@Oldboy

days needs to be adjusted as time goes on too. It’s not just years which is being changed. (Given the nature of your code, it’s safe to say your code won’t work in this situation.)

Another issue with this routine is its definition. It is defined to return a BOOL when in fact there is no information to be returned.
There is no failure mode, so returning TRUE or FALSE is not necessary. This routine should be defined as void.

If the code has access to the POSIX time functions, this code can be used instead. It might not be the fastest code, but it is quite readable.

#define EPOCH_OFFSET 315532800 /* 1980-01-01 00:00:00Z */
BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)
{
struct tm *tm;
time_t now;

now = EPOCH_OFFSET + days * 86400;
tm = localtime (&now);

if (tm == NULL)
return FALSE;

lpTime->wDay = tm->tm_mday;
lpTime->wDayOfWeek = tm->tm_wday
lpTime->wMonth = tm->tm_mon + 1;
lpTime->wYear = tm->tm_year + 1900;

return TRUE;
}

And if we don’t have access to the POSIX time functions we can use this:

for (;;) {
int yeardays = IsLeapYear (year) ? 366 : 365;

if (day <= yeardays)
break;

day -= yeardays;
year += 1;
}

Whoops. I left out a continue… I meant to say:

while(days > 365) {

if(IsLeapYear(year)) {
–days;
continue;
}

days -= 365;
++year;
}

I find this discussion (especially the opinions) to be very interesting. I haven’t coded anything in a LONG time, but I have a question about the use of a while loop, Jack’s proposal to use 28.25 and 365.25, and Bryant’s response due to 100/400 leap years.

Since the Zune 30 was produced in 2007, why not just begin the calculation at 2001 instead of 1980, allowing 99 years until the next leap-year skip, well beyond the life of any consumer product? You could then use simple math and integers once to determine the number of days. I know there’d be a y21k bug, but no Zune is going to be in service then.

As I said. It’s been a long time, so I’m probably missing something. What is it?

@jan:

In response to “since that code is under shared source, where were the opensourcies on that one!!”

It’s a *zune*. Like anyone cares!

But hey, given that we can actually see the code, we can all chuckle to ourselves and see why it went wrong. Tried that with a closed source binary blob. A bit hard to cover up source code you can *see*.

The average length of a year is 365.2425 (365 + 1/4 – 1/100 + 1/400)

year = floor(day / 365.2425)

Did someone say use floor? Floor is notorious for having major rounding issues. It is *not* reliable..

I am surprised how many people accept that looping is an acceptable way to solve this simple problem. I would give any programmer an “F” that would attempt to calculate leap years using loops like this. Sadly, most computer science students are poor at math.

P.S. Bryant, just because “most” lower-level hardware providers use the same epoch doesn’t mean that it should be used without current justification. Kind of reminds me when I go rafting. The first person in a line of rafts goes through a rapid and flips. The second follows the first and flips. The third, fourth, fifth, etc all follow along and run into the same troubles.

I prefer engineers/designers/architects that learn from the past — what was done right and what was done wrong — and can justify how what they have chosen applies to the current task at hand.

One liner:
for (int daysThisYear; days < (daysThisYear = (IsLeapYear(year) ? 366 : 365)); days -= daysThisYear, ++year);

@Jon Sebastiani

Depends on language obv, if C then can work out if need to decrement or increment easily enough. Infact thats how Mozilla’s javascript engine does it.

@XS “I for one find it hilarious that people are spending this much effort talking about optimizing a piece of code which is rarely ever run on the device.”

It runs every time the device boots. What are you talking about?

its amazing to see proper coding practices going to the way side so that profit margin can be improved. Mental note Microsoft….break your own code before breaking your customers pocket book. Its a failure in common coding practices.

This is clearly specified as part of the c std and there’s no need to re-implement the wheel (incorrectly and with a strange loop rather than a simple linear algorithm available from any good collection of numerical algorithms). strftime could have saved them quite a bit of embarrassment.

@Ernie

Most of Microsoft’s teams have 1:1 Dev:QA ratios, though I don’t know about Freescale.

If debugging is the process of removing the bugs from code, programming must be the process of inserting the bugs.

As a matter of professionalism, I check each few lines of code as I go and I do not assume Q/A will come along after me and do my job for me. After I have done my due diligence and made the code the best I can, it is valuable for a different set of eyes to observe the performance of my code. Programmers tend to test their code with the same assumptions they used to write it. When programmers are under such time constraints that they cannot adequately test the code as they go, the process has broken down. The worst case would occur if we became arrogant and assumed our bugs were someone else’s problem. I for one am thankful when someone else is willing to help me perfect my code, and I thank them profusely if they actually find a bug.

As for why 1980, I believe that the time handling routines in Unix were written around that time, and a time_t (long) was expected to be adequate to hold the number of seconds as far into the future as the phone company’s operating system was expected to last.

It has been at least a decade since programmers had to face the reality that there was no longer time to write each and every routine from scratch. Libraries and toolkits are part of what has helped improve developer productivity and you cannot be competitive if you don’t leverage off them where possible. I still hand code the lowest level when there is a reason, but I agree the C standard library time handling routines would have saved a lot of trouble.

@stu

In a number of cases, iterated subtraction is more efficient than division. One such example would be on a portable device which doesn’t run a desktop/laptop processor.

I should note that Jason has a (small) point. The boot process for the device is pretty slow as it is. Faster boot times wouldn’t be a bad thing, even though this would only affect it by a very miniscule amount.

I’ll just add to the legions already screaming USE THE DATE OBJECT! They must get paid by the line.

choose your language, it’s just as easy…

>>> import datetime
>>> datetime.datetime.now().year – 1980
29
>>> days_left_delta = datetime.datetime(datetime.datetime.now().year + 1, 1, 1) – datetime.datetime.now()
>>> days_left_delta.days
360
>>>

Hmmm. . . After reading so much ado over a little while loop, I have to ask myself, “Is it any wonder Windows is so over-bloated?” Also, I realize now why we have patch tuesday. (IANAC++P).

Some suggestion claimed it was hard to test for. It isn’t, it is a clear edge/boundary case and those are one of the key things to test if you are trying to limit the amount of tests you write. Any good testing strategy should pick that up and any good review of tests should spot that it was missed. I’d say 30 test cases that took about 20 minutes to do. But such a “simple” piece of code is exactly the sort of thing that people just try to test as part of the whole application because hey it’s less than a dozen lines of actual functional code and only used a little bit! Exactly the sort of dark corner where oops ups usually lurk.

1. Test every condition which could happen in every single loop in your code (though, as Matt Boehm points out in the comments, this might be a tad bit hard).
There is an additional issue which should be mentioned about trying to test every possible condition in a program. Lets say there are just 20 if statements in a simple device driver then this means the QA staff or the developers who need to come up with 2^20 or 1,048,576 test cases to properly test their device driver. Possibly their grandchildren could complete writing all the test cases for them.

Regarding testing every loop/permutation, I have always been curious: how do you do it? Someone has to sit down and document the expected correct result for every loop/permutation. Surely he would have died of old age before he finishes a small percentage of it.

I always thought that void SomeMethod(int x, int y) is already a big disaster. The person who wants SomeMethod has to specify 2E+128 outcomes that he wants. So I have given up a long time ago about wanting to work in General Dynamics.

The people who do not forgive the Zune bug are simply armchair critics. I can bet they will be most unwilling to pay $20,000,000 for an MP3 player.

I design mission-critical software for embedded powerpc and ARM processors. I also design the ASIC for custom processors. I have been in this business for 13 years. It’s tedious, boring, and I seriously regret ever getting my graduate degrees in computer science and electrical engineering. I will say this: It’s not the programmer’s fault! The lead engineer should have mitigated this problem at a higher level. If I relied on my code monkeys to output perfect code, there would be the blood of a lot of innocent people on my hands. . . literally.

Testing with “100% code coverage” doesn’t work: Unit Test Tools like VectorCAST can give you code coverage statistics, cyclomatic complexity, and paths exercised in Unit Testing, but that’s NO GUARANTEE your test actually exercised the code under all possible in-the-wild conditions. I can easily get 100% code coverage, yet the code does not work? Why? Because 100% code coverage only says that every line of code must be covered which is different from every code path. Even though the lines of code were “covered”, the result of the test may not have been dependent upon that path. Let’s say you got 100% code coverage via two tests: One test covers paths A and B. Test two covers C. That’s considered “100% code coverage” as it’s defined by unit test tools, yet the path A->B->C was never tested nor were any significant permutations of that. Furthermore, the test result of your Unit Test may have resulted in the same answer regardless of the existence of an error in that “covered” path. These are all situations I have run into.

My point is this: it’s impossible to catch every bug in an embedded program and perfection has never happened and does not exist. It’s really the lead engineer’s job to mitigate the risk of misbehaving code at a higher level. Coders are usually working mindlessly to higher level design. Here’s how I mitigate bad coding:

Rule #1: No loops. All code must be in the form of an FSM (finite state machine) with a WATCHDOG TIMER for each state.
Rule #2: No dynamic memory allocation. Screw what you learned in Computer Science. All structures must be static or global.

Rule #1 eliminates the possibility of the program hanging from infinite loops. (Zune problem)
Rule #2 eliminates the possibility of crashing due to overflow or null pointer.

Embedded C is far different from C programming. This industry isn’t about making code fast and efficient. It’s about making it manageable so that if bugs are discovered they can be found. All of the suggestions to make this code more concise would just make bugs more difficult to find. Verbose and explicit coding may seem juvenile to people still in school, but that’s the way people expect you to code in the real world. No one cares that you can write code in one line what might take an idiot 10 lines of code to accomplish. The byte code will look identical because of compiler optimizations.