* Ingo Molnar <mi...@kernel.org> wrote:
> But that's my point, I believe the false positive rate is pretty low in fact,
> due
> to three factors:
>
> - 90% of the warnings get fixed by developers, we never see them upstream
>
> - I'd say a majority (say 70%) of the remaining warnings are flagging
> 'complexity
> bugs'
>
> - only a residual 3% are obnoxious ones.
>
> But these remaining 3% are the ones we are seeing again and again in various
> compiler output, so we tend to get a subjective impression that this warning
> produces countless false positives.
And note that I am well aware of the real risk this poses: people will ignore
real
warnings if there are so many residual false positives.
I think this approach worked pretty well for perf:
> So I *think* the better option would be to do what we are doing in the perf
> tooling: force a build error for these warnings (by default, with an option
> available to make it build). That flushes them out and also makes it sure
> that
> those questionable sequences of code never get upstream to begin with.
... but might not be appropriate for the kernel which is a 2 orders of
magnitude
larger code base.
Thanks,
Ingo
