mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Ingo Molnar <mingo@elte.hu>, julia Lawall <julia@diku.dk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Am??rico Wang <xiyou.wangcong@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] sysctl.c: Change a .proc_handler = proc_dointvec to &proc_dointvec,
Date: Sun, 15 Nov 2009 09:31:39 -0800	[thread overview]
Message-ID: <1258306299.21668.30.camel@Joe-Laptop.home> (raw)
In-Reply-To: <20091115103307.GB24931@elte.hu>

On Sun, 2009-11-15 at 11:33 +0100, Ingo Molnar wrote:
> * Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Ingo Molnar <mingo@elte.hu> writes:
> > > * Joe Perches <joe@perches.com> wrote:
> > >> On Sun, 2009-11-15 at 09:11 +0100, Ingo Molnar wrote:
> > >> > * Am??rico Wang <xiyou.wangcong@gmail.com> wrote:
> > >> > > On Sat, Nov 14, 2009 at 05:52:05PM -0800, Joe Perches wrote:
> > >> > > >Seems to be a typo.
> > >> > > Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
> > >> > (Cc:-ed Eric who is running the sysctl tree these days)
> > >> > Almost everywhere in the kernel we use the shorter version, so all of 
> > >> > sysctl.c should eventually change to that variant.
> > >> It's closer to 50/50, but it's 1 vs 133 in that file.
> > >> $ grep -Pr --include=*.[ch] '\.proc_handler\s*=\s*&\s*\w+' * | wc -l
> > >> 339
> > >> $ grep -Pr --include=*.[ch] '\.proc_handler\s*=\s*[^&]\s*\w+' * | wc -l
> > >> 432
> > > I did not mean this specific initialization method of proc_handler, i 
> > > meant pointers to functions in general.
> > There was an argument put forward by Alexy (I think) a while ago.  
> > That argued for the form without the address of operator.
> > The reason being that without it you can do:
> > #define proc_dointvec NULL
> > in a header when sysctl support it compiled out.  Using address of
> > you wind up with stub functions in sysctl.c to handle the case when
> > sysctl is compiled out.
> > It isn't a strong case but since not using & is also shorter and as 
> > Ingo pointed out more common I think no & wins.
> I can think of another reason as well: the & operator can be dangerous 
> if code is changed from functions to function pointers.
> 
> The short form:
> 
>   val = do_my_func;
> 
> will work just fine if 'my_func' is changed to a function pointer, as it 
> will evaluate to the value of the function pointer - i.e. the address of 
> the function.
> 
> The longer form:
> 
>   val = &do_my_func;
> 
> might break in a subtle way, because it will now become the address of 
> the function pointer - not the function address.
> 
> Combined the shortness, the NULL init, the function pointer invariance, 
> plus existing in-kernel practice all suggest that the short form should 
> be used.
> 
> ( i didnt want to turn this small issue into a long argument - it's just
>   that the code was going in the wrong direction. )

That sounds like something coccinelle would do well,
so I've cc'd Julia Lawall.

http://lkml.org/lkml/2009/11/15/55


  parent reply	other threads:[~2009-11-15 17:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-15  1:52 Joe Perches
2009-11-15  6:59 ` Américo Wang
2009-11-15  8:11   ` Ingo Molnar
2009-11-15  8:28     ` Joe Perches
2009-11-15  8:39       ` Ingo Molnar
2009-11-15 10:04         ` Eric W. Biederman
2009-11-15 10:33           ` Ingo Molnar
2009-11-15 12:29             ` Eric W. Biederman
2009-11-15 13:57               ` Ingo Molnar
2009-11-15 14:14                 ` Eric W. Biederman
2009-11-15 17:31             ` Joe Perches [this message]
2009-11-15 18:20               ` Julia Lawall
2009-11-15 19:23                 ` Joe Perches
2009-11-15 20:40                   ` Julia Lawall
2009-11-15 20:53                     ` Arnd Bergmann
2009-11-15 22:54                       ` Julia Lawall
2009-11-15 21:13                     ` Joe Perches
2009-11-15 21:34                       ` Julia Lawall

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=1258306299.21668.30.camel@Joe-Laptop.home \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=julia@diku.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=xiyou.wangcong@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®