Redundancies often reveal bugs
bearophile
bearophileHUGS at lycos.com
Thu Sep 30 18:12:53 PDT 2010
Here (pdf alert) I have found a very simple but interesting paper that has confirmed an hypothesis of mine.
This is a page that contains a pdf that shows a short introduction to the paper:
http://www.ganssle.com/tem/tem80.htm
This is the paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002:
www.stanford.edu/~engler/p401-xie.pdf
A trimmed down quote from the tem80 page:
>Researchers at Stanford have just released a paper detailing their use of automated tools
to look for redundant code in 1.6 million lines of Linux. "Redundant" is defined as:
- Idempotent operations (like assigning a variable to itself)
- Values assigned to variables that are not subsequently used
- Dead code
- Redundant conditionals
They found that redundancies, even when harmless, strongly correlate with bugs. Even
when the extra code causes no problems, odds are high that other, real, errors will be
found within a few lines of the redundant operations.
Block-copied code is often suspect, as the developer neglects to change things needed for
the codes new use. Another common problem area: error handlers, which are tough to
test, and are, in data Ive gathered, a huge source of problems in deployed systems.
The authors note that their use of lint has long produced warnings about unused variables
and return codes, which they've always treated as harmless stylistic issues. Now it's clear
that lint is indeed signalling something that may be critically important.
The study makes me wonder if compilers that optimize out dead code to reduce memory
needs aren't in fact doing us a disservice. Perhaps they should error and exit instead.<
This study confirms that situations like:
x = x;
often hide bugs, unused variables are often enough (as I have suspected, despite what Walter said about it) a sign for possible real bugs, and assigned but later unused variables too may hide bugs.
This paper has confirmed that some of my enhancement requests need more attention:
http://d.puremagic.com/issues/show_bug.cgi?id=3878
http://d.puremagic.com/issues/show_bug.cgi?id=3960
http://d.puremagic.com/issues/show_bug.cgi?id=4407
situations like x=x; reveal true bugs like:
class Foo {
int x, y;
this(int x_, int y_) {
this.x = x;
y = y;
}
}
void main() {}
Now I think that such redundancies and similar things often enough hide true bugs. But what to do? To turn x=x; into a true error? In a comment to bug 3878 Don gives a situation where DMD may raise a true true compile-time error. But in other cases a true error looks too much to me.
Bye,
bearophile
More information about the Digitalmars-d
mailing list