C++ static analysis

[bearophile]

Don:

> I would say that disallowing it would _always_ lead to clearer code.

OK. It's in Bugzilla since some time:
http://d.puremagic.com/issues/show_bug.cgi?id=5409
(But if we want to disallow something then we have to list exactly what syntax are not allowed.)


> Making #7 an error would break a lot of my code, unless it were done in
> a really complicated way (allowing boolean expressions, but not integral
> ones other than UnaryExpressions). And that seems quite hard to justify.

I think in this case introducing complex rules is not good.

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

auto z = x * (y ? 10 : 20);


> But I don't find the other cases convincing. They don't seem any more
> likely to be bugs than not. For example, a variation of case #3:
> if (1 || y) {}
> is common and completely legitimate. Disallowing that would be very
> annoying.

I agree that sometimes it's not a bug (example: the 1 is the __ctfe pseudo-constant). Always true or always false boolean conditions (unless they are just a single "true", "false", "0" or "1" literal) are sometimes associated with bugs. Good C lints give just a warning in this case, no error.
I agree that statically disallowing this in all cases is too much harsh.

------------------

The midway cases are #5 and #6. If I write manually code like that, it's probably a bug.

A similar case (auto-assign):
x = x;

Or even (auto-assign, through alias):
alias x y;
x = y;

Or even (repeated assign):
x = 10;
x = 10;

(repeated assign, this happens often enough, the second variable is not x):
x = Foo.barx;
x = Foo.bary;

On the other hand automatic code generation (in CTFE) sometimes produces some redundancy in code, this may cause some false positives. But similar redundancies that often hide bugs. So I think this class of troubles deserves more thinking.


A common bug in my code is this one, I have had something like this six times or more:
http://d.puremagic.com/issues/show_bug.cgi?id=3878

Bye,
bearophile