Wed Jan 29 09:38:00 GMT 2014
On Tue, Jan 28, 2014 at 10:24 PM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> `On Tue, Jan 28, 2014 at 1:10 PM, Thomas Schwinge
> <email@example.com> wrote:
>> OK, I agree to all of that, but I'd assume that if the compiler doesn't
>> do such value tracking to see whether all cases have been covered, it
>> also souldn't emit such possibly unitialized warning, to not cause false
>> positive warnings.
> The -Wuninitialized warning is full of false positives.
> It is the canonical example of why warnings that are driven by
> optimizations are difficult for users in practice.
Indeed. In this case it's of course the "optimistic" data-flow done by
the -Wuninit pass - if it were to assume that a value is initialized if
it cannot prove it isn't then we'd get no false positives but also a lot
of false negatives. Currently if it cannot prove it is initialized on a path
the pass assumes it is uninitialized on it.
As always you could do both dataflow kinds and add an extra "maybe"
before cases where both analyses do not agree.
Note that the current "maybe" is supposed to mean that there exists
a path to the use where the value seems to be(!) uninitialized. In contrast
to there exists a path to the use where the value _is_ uninitialized or
even "all paths to the use have the value uninitialized" (the cases where
no maybe is emitted).
More information about the Gcc-patches