Is there anyway a valgrind message "Conditional jump or move depends on uninitialized value" can be a so called 'false positive'

Question

Most questions I find here provide a piece of code and get answered by someone pointing to the actual error. My question is about conditional jumps on uninitialized values in general. I can understand that a piece of memory should not necessarily be cleaned at the end of a program if one is sure this allocation is done only once and will probably be needed during the lifetime of a program. As far as I remember the GType system leaves a lot of unfreed memory when the program terminates. These unfreed blocks can be seen as 'false positives'. But can a 'conditional jump or move on uninitialized value' be a false positive? The only thing I can come up with is someone implementing a (bad) randomize function by just reading a random address (where the random address itself is the tricky part ;). Another example could be hardware mapped to a part of the memory which is then read, but this is mostly done by drivers and not by normal user applications. Is there any other example (preferably C) which could cause such a false positive?

Answer 1

Absolutely! I once had C code of the form

// compute a and, possibly, b
if (a && b) {
    // do stuff
}

in which b was guaranteed to be initialized if a were true. Thus, there was no way that an uninitialized value of b could cause a problem. However, gcc, when optimizing sufficiently aggressively, decided to check the value of b first. This was acceptable since neither check had any side effects, but it still caused valgrind to complain.

Answer 2

What valgrind is reporting is that it sees a jump based on a read from a location for which it knows that it was allocated by the program but for which it hasn't seen an initialization. This might happen if the object is initialized by some magic that valgrind doesn't know about. Architectures evolve constantly and maybe you have an instruction or register type that valgrind doesn't know enough about.

Another difficult source of such non-initializations are unions. Two sources:

• Per default, for these only the first member is initialized and so when another field goes beyond that first member that part might be uninitialized.
• If the members of the union are struct they may have padding bytes at different places, and so part of a member may be uninitialized if you assigned to a different member.

In some cases it might be legitimate to even read these things (through a unsigned char[] for example) so if you consider such things as a bug (false positive) or not is a matter of perspective.