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


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/

Relevant Pages

  • Re: [git pull] x86 fixes
    ... wish people looked at warnings that are introduced by their ... | commit fa2144ba9a31d1d0dc9607508576c3850e0d95b1 ... time the warnings show real bugs and we want to fix real bugs ... mce: remove incorrect __cpuinit for mce_cpu_features ...
    (Linux-Kernel)
  • Re: changed queries save automatically
    ... Not exactly a "tiny" bug is it? ... A query not prompting you about saving it is one of the symptoms of this ... macro or code someone has Set Warnings to Off but forgot to Set ... Compacting and repairing closes the database and reopens it. ...
    (microsoft.public.access.queries)
  • Re: A toughy.
    ... Do I ignore all those warnings and using add and remove just delete the darned thing? ... I have always used HTML for my personal posts and the HTML doesn't seem to ... Bug 2. ... Paying users do not have this message in their emails. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: changed queries save automatically
    ... MS is very aware of this bug, and it's been looked at in many ... Just today I create a new query in A03 ... macro or code someone has Set Warnings to Off but forgot to Set ... Compacting and repairing closes the database and reopens it. ...
    (microsoft.public.access.queries)
  • Re: Why arent warnings on by default?
    ... There is a problem with warnings on a larger scale, ... context of published code, most notably modules. ... Does it mean there's a bug in the module, or maybe in my program using ... If warnings in module context really and rightly suggest there's a bug, ...
    (comp.lang.perl.misc)