Wednesday, December 15, 2004

Slashdot | Linux Has Fewer Bugs Than Rivals

Slashdot | Linux Has Fewer Bugs Than Rivals: Re:20-30 bugs per 1000 lines??? (Score:5, Interesting)
by Iphtashu Fitz (263795) on Tuesday December 14, @10:07AM (#11081334)
I'm gonna call bullshit on this figure.

Keep in mind that you need to know the definition of a bug. It's not necessarially what you think it might be, but what the researchers defined. By their definition a condition that could never occur could be considered to be a bug. For example:

int foo ()
{
if (0)
return;

do_something();

return (0);
}

This overly-simple example could be considered to be a bug. If the condition is ever true the function will return an undefined value, but the condition will never be true so you couldn't possibly return an undefined value. It's not at all uncommon to find code with similar logic scattered throughout - improperly defined loops, conditionals, etc. could result in theoretical bugs that no path of execution can actually get to.

Then there are the kinds of bugs that only occur in extremly specific situations. About 13 years ago I had to track down a bug that caused a report package to crash. It took me a while to figure it out but eventually I did. The program would crash only on specific days. It'd only crash on Wednesdays. It'd only crash on certian Wednesdays - Wednesdays in September. Even more specifically, usually only the 3rd or 4th Wednesday in September.

The bug was that whoever wrote the code that printed a header on the reports was extremely anal about memory usage. He calculated exactly how many characters it would take for a buffer to hold the full date. The problem was he miscalculated by 1 character. With "Wednesday" being the longest day spelled out and "September" being the longest month, a 2 digit date (eg. Wednesday September 23) meant that the full date string would overflow the buffer by 1 character. This kind of bug wouldn't show up very often - only a few times a year - but it was a pretty nasty one when it did.

0 Comments:

Post a Comment

<< Home