From: Andrew Morton <akpm@osdl.org>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: jesper.juhl@gmail.com, linux-kernel@vger.kernel.org,
nikita@clusterfs.com, joe@perches.com, tali@admingilde.org,
jbglaw@lug-owl.de, hch@infradead.org, dwmw2@infradead.org,
arjan@infradead.org, dmitry.torokhov@gmail.com,
Valdis.Kletnieks@vt.edu, sam@ravnborg.org, rmk@arm.linux.org.uk,
rusty@rustcorp.com.au, rdunlap@xenotime.net
Subject: Re: [PATCH 00/12] making the kernel -Wshadow clean - The initial step
Date: Sun, 30 Jul 2006 11:29:17 -0700 [thread overview]
Message-ID: <20060730112917.88d9ae4e.akpm@osdl.org> (raw)
In-Reply-To: <m3wt9vj94n.fsf@defiant.localdomain>
On Sun, 30 Jul 2006 19:27:36 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Jesper Juhl" <jesper.juhl@gmail.com> writes:
>
> > 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???).
>
> Possibly, but it could then conflict with something else. Anytime we
> add/change some global symbol, we would have to scan entire kernel
> for conflicts (authors of (yet) off-tree things would hate us).
These things happen. And it's only a warning.
> I don't think it's practical, especially with, IMHO, no real gain.
While I don't recall any kernel bugs which -Wshadow would have saved us
from, I think it's a sensible thing to do - it _might_ save us from a bug,
and we need all the help we can get.
Plus it's often the case that if a local and a global clash, one of the
identifiers was poorly chosen.
next prev parent reply other threads:[~2006-07-30 18:30 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 16:30 [PATCH 00/12] making the kernel -Wshadow clean - The initial step Jesper Juhl
2006-07-30 16:35 ` [PATCH 01/12] making the kernel -Wshadow clean - fix mconf Jesper Juhl
2006-07-30 18:34 ` Paul Jackson
2006-07-30 18:48 ` Jesper Juhl
2006-07-30 19:06 ` Andrew Morton
2006-07-30 19:17 ` Jesper Juhl
2006-07-30 19:51 ` Andrew Morton
2006-07-30 19:57 ` Arjan van de Ven
2006-07-30 20:03 ` Jesper Juhl
2006-07-30 19:32 ` Paul Jackson
2006-07-30 23:41 ` Arnd Bergmann
2006-07-31 15:41 ` Horst H. von Brand
2006-07-31 16:04 ` H. Peter Anvin
2006-07-30 16:36 ` [PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog Jesper Juhl
2006-07-30 16:37 ` [PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h Jesper Juhl
2006-07-30 16:38 ` [PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up' Jesper Juhl
2006-07-30 16:38 ` [PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh Jesper Juhl
2006-07-30 16:39 ` [PATCH 06/12] making the kernel -Wshadow clean - fix checksum Jesper Juhl
2006-07-30 16:40 ` [PATCH 07/12] making the kernel -Wshadow clean - fix vgacon Jesper Juhl
2006-07-30 16:41 ` [PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c Jesper Juhl
2006-07-30 16:42 ` [PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler' Jesper Juhl
2006-07-30 16:42 ` [PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c Jesper Juhl
2006-07-30 16:43 ` [PATCH 11/12] making the kernel -Wshadow clean - USB & completion Jesper Juhl
2006-07-30 16:44 ` [PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global Jesper Juhl
2006-07-30 16:54 ` [PATCH 00/12] making the kernel -Wshadow clean - The initial step Krzysztof Halasa
2006-07-30 17:14 ` Jesper Juhl
2006-07-30 17:27 ` Krzysztof Halasa
2006-07-30 18:29 ` Andrew Morton [this message]
2006-07-30 23:36 ` Arnd Bergmann
2006-08-01 6:17 ` Jan Engelhardt
2006-07-30 19:24 ` Jesper Juhl
2006-07-30 20:09 ` Jan-Benedict Glaw
2006-07-30 19:29 ` Sam Ravnborg
2006-07-30 19:39 ` Jesper Juhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060730112917.88d9ae4e.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=arjan@infradead.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=jbglaw@lug-owl.de \
--cc=jesper.juhl@gmail.com \
--cc=joe@perches.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=nikita@clusterfs.com \
--cc=rdunlap@xenotime.net \
--cc=rmk@arm.linux.org.uk \
--cc=rusty@rustcorp.com.au \
--cc=sam@ravnborg.org \
--cc=tali@admingilde.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.