One year of Coverity work [LWN.net]

One year of Coverity work

Posted Aug 22, 2014 14:28 UTC (Fri) by etienne (guest, #25256)
Parent article: One year of Coverity work

> For example, assigning a variable to itself has no effect

I know some developers see that has bad practice, but I use it to attract attention about a variable - when that variable is initialized and used in only some code-path.

The "design pattern" is basically:
void fct(...) {
int var = var;
if (test1) var = 42;
some_common_function();
if (test2) anotherfct (var);
}

The point is that you shall never use the variable "var" without initializing it, but in this case the compiler will not check for you - "var = var;" is just a "take care" indication to the reader and not a real initialisation.
The other point is that it is not logical to always initialize "var" to a dummy value - there may not be any dummy value available, and usually it would be an error to use that dummy value considering the algorithm.
So when a maintainer see "int var = var;", he will know that "test2" has to be either identical to "test1", or more restrictive than "test1".
I have see too many bug created by bug-fixes applied to just "test1"...

to post comments

One year of Coverity work

Posted Aug 22, 2014 17:18 UTC (Fri) by giraffedata (guest, #1954) [Link] (4 responses)

it is not logical to always initialize "var" to a dummy value - there may not be any dummy value available, and usually it would be an error to use that dummy value considering the algorithm.

A more fundamental reason not to initialize "var" to a dummy value is that it makes the code harder to read. It makes it look like that dummy value is a legitimate value for "var" (after all, it is common for people to cram multiple pieces of information into a variable, so "-1" isn't necessarily a dummy value for a variable named "length"). And it makes it look like "var" is meaningful in the code before it is really set. And that makes it much harder for a reader of the code to detect true used-before-set bugs.

One year of Coverity work

Posted Aug 22, 2014 20:46 UTC (Fri) by etienne (guest, #25256) [Link] (3 responses)

Self initialized variables are surely harder to read - but that is the point: for someone trying to understand (and maybe modify) the source code, that trick tell them to double check everything about its use.
It is obviouly a error to use the value of a self-initialized variable, maybe one day the compiler will flag an error in such case, either at compile time or at run time.
What I need in the algorithm is a "poisonous" value (doesn't exists in C) or a memory area reservation but no visibility at that level (and in the stack, doesn't exists in C).
Myself, if I have a quick bug to correct and I see the obvious test to modify, I will do the change quite quickly; if I see a self initialised variable I will look for the design pattern I was talking of.

One year of Coverity work

Posted Aug 22, 2014 20:50 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

When I see a self-initialized variable, I think "bug", not "here there be dragons". Make your assumptions explicit with a comment please.

One year of Coverity work

Posted Aug 24, 2014 7:24 UTC (Sun) by johill (subscriber, #25196) [Link] (1 responses)

Additionally, if you *don't* initialize the variable then the compiler will be able to warn you if you later create a code path where you forgot...

One year of Coverity work

Posted Aug 31, 2014 12:11 UTC (Sun) by Wol (subscriber, #4433) [Link]

Okay, user-space code, but when I set coding standards at a company, the rule was "all warnings must be explained away".

The reason was precisely that - we had certain code (where we called a commercial library that then called-back our code) that we just couldn't suppress all warnings.

Sometimes you end up between a rock and a hard place, and things like "var = var" are an easy escape route...

Cheers,
Wol