Buried in warnings [LWN.net]

Buried in warnings

Posted Nov 2, 2006 7:26 UTC (Thu) by avik (guest, #704)
In reply to: Buried in warnings by viro
Parent article: Buried in warnings

The latter gets you a warning and data corruption. The former is hidden,
and maybe wastes a cycle when run.

I think that a bogus initialization is better than a genuine uninitialized
variable. It's only worse if you never run the kernel in question.

to post comments

Buried in warnings

Posted Nov 2, 2006 8:48 UTC (Thu) by viro (subscriber, #7872) [Link] (2 responses)

Bogus as in "with value that doesn't make sense". Suppose you used
to have a declaration, then several places assigning to variable,
then several places using it. All paths to the latter actually
pass through the former, so we are fine. gcc is too dumb to prove
that, so it gives a warning. Fine, some kind idio^Wsoul slaps = 0
into declaration. Everything's fine. Until a modification of code
creates a path that *really* does use without assignment. Suddenly
(and without any warning from gcc whatsoever) we get a case that
gets us to use of variable when utter crap is stored in it; the crap
in question is that 0 supplied by helpful idiot several months ago.

Worse yet, code review finding a code path that leads to use without
assignment => OK, we've definitely found a bug. Code review finding
a code path that leads to use of variable explicitly initialized with
something that doesn't make much sense in that place => scratching
head for a long time and trying to figure out whether it's a bug or
not and WTBleedingF was supposed to be done in that place.

Buried in warnings

Posted Nov 2, 2006 15:16 UTC (Thu) by evgeny (subscriber, #774) [Link]

I'd vote for the bogus initialization. If it does cause a bug later on, it is at least reproducible. Tracking down uninitialized vars typically takes much longer. YMMV, of course.

Buried in warnings

Posted Nov 2, 2006 16:58 UTC (Thu) by nevyn (guest, #33129) [Link]

You are saying that the uninitialized vars aren't hidden, but this entire article proves otherwise. There are so many warnings when you compile the kernel that noone is looking at the ones that are being output.

Personally I think there is a huge amount of middle ground, for instance the example code Joe posted could declare the pointer as NULL allocate to it in the if and then just check if the pointer is not NULL later on (Ie. pointer also takes on the job of the seperate boolean).

Finally with decent usage of ASSERT/nonnull you can _very_ easily detect when pointers are still NULL from declaration time.