> Firstly, "may be used uninitialized" can still be a bug.
Of course -- essentially GCC cannot really figure out whether all the
possible paths of execution include initialisation or not and complains
just in case.
> Secondly, latest gcc is *horribly* buggy (and has been so for last several
> releases including 4.1, 4.2 and 4.3 -- 3.x was good). See:
> We'd been hurling all sorts of abuses on gcc for quite long (when it fails
> to detect these "false positive" cases), but now, it turns out it is quite
> easy to write *genuinely* buggy code that still won't get any warnings,
> neither the "is used" nor "may be used" one!
GCC for MIPS used to be problematic enough elsewhere I do not want to
turn back. Even 4.0.x generates bad code, e.g. fs/partitions/msdos.c gets
miscompiled for the big endianness (but not for the little one!).
Compared to that some useless warnings are negligible. This 4.1.2 version
has triggered no problems with the kernel yet (though I suspect it is
still so-so -- e.g. gmp gets miscompiled; which used to be fine with
4.0.x, oddly enough).
> In short, there are three ways to fix these false positive warnings:
> 1. Do nothing, there are enough "uninitialized variable" warnings anyway,
> and hopefully, one day GCC would clean up its act.
> 2. Use uninitialized_var() to shut it up (only if it's genuinely bogus).
> 3. Do something like the following legendary patch :
> i.e., explicitly change the structure/logic of the function to make it
> obvious enough to gcc that the variable will not be used uninitialized.
Perhaps preinitialising to an error value such as -EINVAL would be of
more sense. This way any error paths lacking initialisation are still
reported as errors, even though the classification might be wrong. In
fact more exotic one might be chosen (the glibc manual has some nice
proposals if none of these we currently define fits) so the mistake is