* Borislav Petkov <bp@xxxxxxxxx> wrote:
> Hi Linus,
>
> about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"):
>
> Good! Finally!
>
> This thing was really getting on my nerves.
So I'm worried about this description in the changelog:
| Looking at the warnings produced, every single one I looked at was a false
| positive, and the warnings are frequent enough (and big enough) that they can
| easily hide real problems that you don't notice in the noise generated by
| -Wmaybe-uninitialized.
BUT, isn't this the natural state of things, that the 'final' warnings that don't
get fixed are the obnoxious, false positive ones - because anyone who looks at
them will say "oh crap, idiotic compiler!"?
But over the last couple of years I think we probably had hundreds of bugs avoided
due to the warning (both at the development and at the integration stage) - and
now we are upset about a dozen residual warnings and declare it's all crap?
I am happy to bash GCC's cavalier attitude to warnings any day of the week, but
this argumentation for this particular option looks fishy to me.
Why cannot we say something like:
"a false_positive/false_negative ratio above 10% is considered obnoxious and
won't be tolerated."
?
BTW., one related GCC property I'm pretty upset about: obvious false negatives for
clear unused-variable bugs, which caused pain and hours of debugging. An example
is this recent fix:
commit e01d8718de4170373cd7fbf5cf6f9cb61cebb1e9
Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Date: Wed Jan 27 23:24:29 2016 +0100
perf/x86: Fix uninitialized value usage
...
Only took 6 hours of painful debugging to find this. Neither GCC nor
Smatch warnings flagged this bug.
... and my worry here is that we are now telling GCC: "don't you dare generate a
false positive warning!" - at which point GCC folks will add even MORE heuristics
to avoid false positives that generate even more false negatives which are hurting
us asymmetrically more than the couple of low intensity minutes spent per false
positive could ever hurt us ... ??
So what's the logic here? What am I missing?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
