LCA: Static analysis with GCC plugins [LWN.net]

LCA: Static analysis with GCC plugins

Posted Jan 25, 2010 17:42 UTC (Mon) by iabervon (subscriber, #722)
In reply to: LCA: Static analysis with GCC plugins by tialaramex
Parent article: LCA: Static analysis with GCC plugins

I'd actually say that the goal is finding things that are possibly correct but misleading. It is well-defined what happens if you shadow a variable in C++, but someone who encounters a variable reference two pages from the start of a method that matches one of the method arguments is likely to overlook the fact that there's a shadowing declaration on the middle page.

Similarly, the precedence of shifts is unintuitive when combined with addition and subtraction; a line that combines these without parentheses is likely to either get the wrong value, or to confuse people.

Static analysis tools can do things better than language definitions in this area, too. A static analysis tool can decide whether to warn about something based on the textual size of the scope in which a variable is shadowed, representing an approximation of the likelihood of people not seeing the shadowing declaration, which is not something the language definition should be trying to estimate.

(Log in to post comments)

Shadowing a class member: wrong?

Posted Jan 29, 2010 16:35 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I'd say an even more basic goal is to provide the coder with tools to assist in his personal coding style. If you like to use local variables that shadow class members, fine. Don't turn on this checker. But if you avoid that because you find you do it wrong too often, turn on the checker.

Personally, I wouldn't use this, but would really like to see a checker that catches every time I refer to a class member implicitly (i.e. without "this->". To prevent confusion about what is a class member and what is local, I observe a discipline of always referring to the former with this->, but get burned sometimes when I neglect to define a local variable and implicitly get a class member instead.

Shadowing a class member: wrong?

Posted Jan 29, 2010 17:55 UTC (Fri) by iabervon (subscriber, #722) [Link]

Obviously, it has to be on a project scale instead of an individual scale; it doesn't help if you never make a mistake based on a variable shadowing, if it's not common in a particular project and other people make mistakes because of that code.

In general, it's probably best to either always use "this->" or never use it (and never shadow members) within a given codebase. Either way works, but any mixture leads to patches which can't be reviewed easily (that is, you can't tell from the function header and 3 lines of context whether a patch is right).