[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bqjxooog.fsf@javad.com>
Date: Tue, 13 Feb 2007 22:14:23 +0300
From: Sergei Organov <osv@...ad.com>
To: "Pekka Enberg" <penberg@...helsinki.fi>
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
J.A. MagallÃón
<jamagallon@....com>, "Jan Engelhardt" <jengelh@...ux01.gwdg.de>,
"Jeff Garzik" <jeff@...zik.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb
"Pekka Enberg" <penberg@...helsinki.fi> writes:
> On 2/13/07, Sergei Organov <osv@...ad.com> wrote:
>> May I suggest another definition for a warning being entirely sucks?
>> "The warning is entirely sucks if and only if it never has true
>> positives." In all other cases it's only more or less sucks, IMHO.
>
> You're totally missing the point.
No, I don't.
> False positives are not a minor annoyance, they're actively harmful as
> they hide other _useful_ warnings.
Every warning I'm aware of do have false positives. They are indeed
harmful, so one takes steps to get rid of them. If a warning had none
false positives, it should be an error, not a warning in the first
place.
> So, you really want warnings to be about things that can and
> should be fixed.
That's the definition of a "perfect" warning, that is actually called
"error".
> So you really should aim for _zero false positives_ even if you risk
> not detecting some real positives.
With almost any warning out there one makes more or less efforts to
suppress the warning where it gives false positives, isn't it? At least
that's my experience so far.
-- Sergei.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists