Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix

[Steven Rostedt]

On Wed, 10 May 2006, Al Viro wrote:

> On Wed, May 10, 2006 at 02:11:54PM -0700, Daniel Walker wrote:
> > > I really don't see why it couldn't be added.  What's the problem with it?
> > >
> > > I mean, I see lots of advantages, and really no disadvantages.
>
> Your vision is quite selective, then.

And maybe so is yours.

>
> > We are in complete agreement .. The only disadvantage is maybe we cover
> > up and real error

I disagree here that it covers up any bug. See below.

>
> ... which is more than enough to veto it.  However, that is not all.
> Consider the following scenario:
>
> 1) gcc gives false positive
> 2) tosser on a rampage "fixes" it
> 3) code is chaged a month later
> 4) a real bug is introduced - one that would be _really_ visible to gcc,
> with "is used" in a warning
> 5) thanks to aforementioned tosser, that bug remains hidden.

What's the difference in seeing a warning in a compile, and noticing that
there's a wrapper around a variable?  In fact, that wrapper is more
of a flag that something might be broken than a warning that everyone is
use to seeing.  In step 3, the code that is changed, should either remove
the wrapper on the variable, or recompile with the wrapper defaulted to
warn.  The bug is never hidden due to the fact that you can keep the
warnings on.

So if you like to look for real warnings, you can compile it with the
false positives turned off, and if you don't trust the hidden warnings,
use a compile where the false positives stay on.  So it's now a choice to
which you perfer.  Not everyone likes to see a bunch of false positives,
and have to fight to find the real bugs.

As stated before, gcc (and any other program) is not perfect, and can't be
right all the time.  So it takes the side of aggressive warnings. But with
the help of the programmer, it only needs to warn on actual bugs.

This solution does _not_ hide the bug in step 5.  It only surpresses it to
those who don't care.

>
> And that's besides making code uglier for no good reason, etc.

The ugliness of the code, only helps to point out that there might be a
problem.  So instead of constantly weeding through warnings in search of
real bugs, you can look through the code once in a while to see if
something was missed.

>
> Consider that preemptively NAKed.
>

Preemptive strikes are usually never a good thing.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/