[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a8748490607301014rf04b6cew9d991635a7834277@mail.gmail.com>
Date: Sun, 30 Jul 2006 19:14:06 +0200
From: "Jesper Juhl" <jesper.juhl@...il.com>
To: "Krzysztof Halasa" <khc@...waw.pl>
Cc: linux-kernel@...r.kernel.org, "Andrew Morton" <akpm@...l.org>,
"Nikita Danilov" <nikita@...sterfs.com>,
"Joe Perches" <joe@...ches.com>,
"Martin Waitz" <tali@...ingilde.org>,
"Jan-Benedict Glaw" <jbglaw@...-owl.de>,
"Christoph Hellwig" <hch@...radead.org>,
"David Woodhouse" <dwmw2@...radead.org>,
"Arjan van de Ven" <arjan@...radead.org>,
"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
"Valdis Kletnieks" <Valdis.Kletnieks@...edu>,
"Sam Ravnborg" <sam@...nborg.org>,
"Russell King" <rmk@....linux.org.uk>,
"Rusty Russell" <rusty@...tcorp.com.au>,
"Randy Dunlap" <rdunlap@...otime.net>
Subject: Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
On 30/07/06, Krzysztof Halasa <khc@...waw.pl> wrote:
> Hi,
>
Hi Krzysztof,
> Jesper Juhl <jesper.juhl@...il.com> writes:
>
> > This is a series of patches that try to be an initial step towards making
> > the kernel build -Wshadow clean.
>
> I'm not sure such patches improve situation.
>
> > It'll help us keep our namespaces separate.
>
> Nope, it's exactly opposite - now we have separate namespaces and
> -Wshadow reduces that separation.
>
I don't agree. -Wshadow lets the compiler help you ensure that you
don't accidentally use a symbol from a local scope when you think you
are using one from an enclosing scope (global or not).
Bugs resulting from such use can be hard to track down and if we can
get the compiler to help us avoid them I think that's a win.
> Currently you don't have to worry about the universe when you write
> a piece of code, and more importantly the universe doesn't have to
> worry about each function and each private variable. I'm not sure
> changing that is a good idea.
I think it's a good thing that we have to take a little more care when
choosing global function and variable names... Take up() for example -
in my (very humble) oppinion that is a very bad name for a global
function - it clashes too easily with local function and variable
names, and a programmer who's not careful may end up calling the
global up() when he wants the local and vice versa (a much better name
would have been sem_up() - should we change that???).
I think it's a good think if we in the future name our global stuff
with more care and stick a big fat warning in the face of programmers
who introduce local stuff that shadows something else.
I don't agree with you and I don't know how to convince you, but I
still appreciate your feedback.
Thanks.
I'll leave it to people higher in the hierarchy to decide if these
patches should be applied or not ;)
Keep that feedback flowing people :-)
--
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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