Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()





On Wed, 29 Nov 2006, Jesper Juhl wrote:

I would venture that "-Wshadow" is another one of those.

I'd agree, except for the fact that gcc does a horribly _bad_ job of
-Wshadow, making it (again) totally unusable.

For example, it's often entirely interesting to hear about local variables
that shadow each other. No question about it.

HOWEVER. It's _not_ really interesting to hear about a local variable that
happens to have a common name that is also shared by a extern function.

There just isn't any room for confusion, and it's actually not even that
unusual - I tried using -Wshadow on real programs, and it was just
horribly irritating.

In the kernel, we had obvious things like local use of "jiffies" that just
make _total_ sense in a small inline function, and the fact that there
happens to be an extern declaration for "jiffies" just isn't very
interesting.

Similarly, with nested macro expansion, even the "local variable shadows
another local variable" case - that looks like it should have an obvious
warning on the face of it - really isn't always necessarily that
interesting after all. Maybe it is a bug, maybe it isn't, but it's no
longer _obviously_ bogus any more.

So I'm not convinced about the usefulness of "-Wshadow". ESPECIALLY the
way that gcc implements it, it's almost totally useless in real life.

For example, I tried it on "git" one time, and this is a perfect example
of why "-Wshadow" is totally broken:

diff-delta.c: In function 'create_delta_index':
diff-delta.c:142: warning: declaration of 'index' shadows a global declaration

(and there's a _lot_ of those). If I'm not allowed to use "index" as a
local variable and include <string.h> at the same time, something is
simply SERIOUSLY WRONG with the warning.

So the fact is, the C language has scoping rules for a reason. Can you
screw yourself by usign them badly? Sure. But that does NOT mean that the
same name in different scopes is a bad thing that should be warned about.

If I wanted a language that didn't allow me to do anything wrong, I'd be
using Pascal. As it is, it turns out that things that "look" wrong on a
local level are often not wrong after all.

Linus
-
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: Newbie query
    ... looking at the assembly generated by gcc. ... From this location, our parameters (pushed on the stack by our caller before the "call") and our local variables can be accessed at known offsets from ebp, even if we alter esp. ...
    (comp.lang.asm.x86)
  • Re: how to ask GCC to automatically initialize local variables
    ... > How can I ask GCC to automatically initialize local variables? ... > I think some compilers do that and some not, ... > portability problem. ...
    (comp.unix.programmer)
  • Re: how to ask GCC to automatically initialize local variables
    ... >> How can I ask GCC to automatically initialize local variables? ... >> I think some compilers do that and some not, ... >> portability problem. ...
    (comp.unix.programmer)
  • Re: [PATCH] Dont compare unsigned variable for <0 in sys_prctl()
    ... it's often entirely interesting to hear about local variables ... way that gcc implements it, it's almost totally useless in real life. ... simply SERIOUSLY WRONG with the warning. ... the C language has scoping rules for a reason. ...
    (Linux-Kernel)
  • Re: How do you do this?
    ... Am I missing something? ... involves using hooks in the underlying implementation. ... There is nothing wrong for the language not letting you ... changing the local variables directly. ...
    (comp.lang.scheme)