C++ static analysis

bearophile bearophileHUGS at lycos.com
Thu May 5 17:37:41 PDT 2011


Through Reddit I've seen another document that shows common little bugs in C/C++ code found by a static analysis tool. The bugs shown seem to be real, from real software:
http://www.slideshare.net/Andrey_Karpov/add2011-en

>From the slides I have selected seven of the bugs, here translated to D2:


enum uint FLAG1 = 0b001;
void main() {
    int x = 1000;
    int y = 1;
    if (!y & x) {} //#1

    uint flags;
    if (flags && FLAG1) {} //#2

    if (y == 0 || 10 || y) {} //#3

    int i;
    for (i = 0; i < 10; i++)
        for (i = 1; i < 5; i++) {} //#4

    if (x || x) {} //#5

    if (x) y = 1; else y = 1; //#6

    auto z = x * y ? 10 : 20; //#7
}


Notes about the bugs:
- In #1 the programmer meant to write if(!(y & x)). This is often a bug.
- In #2 the programmer probably meant to use & instead of && to intersect the flags.
- In #3 the boolean condition is always true, and y is ignored.
- In #4 there are two nested loops with the same index variable.
- In #5 the two conditions in or are the exactly the same. When this happens, it's probably a bug.
- In #6 the two branches of the if are exactly the same. When this happens, it's probably a bug.
- In #7 the programmer may have misunderstood the precedence levels between ?: operator and the * (mult) operator.

Notes about D2:
- Bug #1 is common, easy to catch statically, so I think it's worth catching by D2 language (we have discussed this bug in past too, but the catching code is not present yet). I think D2 may require parentheses here.
- Regarding #2, that static analysis tool catches it too, it seems, but I don't know how to catch it, or if it's worth catching. But it's probably a not so uncommon bug.
- #3 is an example of always true or always false boolean expression (that's not 0/1 or true/false). It's a case that asks for considerations similar of #5 ones.
- Bug #4 is probably easy to find, but in D is less common, because you usually use foreach, or for with local index variable (that D doesn't allow you to redefine). Once in a while that kind of code is correct, maybe.
- Bug #5 and #6 are similar. Simular redundancies often are bugs. But I don't know if D2 wants to actually turn this correct code into a real compile-time error. But it's worth thinking more about it.
- Bug #7 is easy to catch, and the fix is to ask for more parentheses. But I think it's not a so common bug.

So:
- I suggest to change D2 to catch #1 statically.
- I encourage you to think more about what to do with bugs #3, #5, #6 (there is another related bug, with class/struct members assignments, http://d.puremagic.com/issues/show_bug.cgi?id=3878 ).
- Maybe think about fixing #7 too. ?: operators are a rich source of bugs anyway.

Bye,
bearophile


More information about the Digitalmars-d mailing list