public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Joe Perches <joe@perches.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 11:33:07 +0100	[thread overview]
Message-ID: <20091115103307.GB24931@elte.hu> (raw)
In-Reply-To: <m1hbswm7dk.fsf@fess.ebiederm.org>


* 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. )

	Ingo

  reply	other threads:[~2009-11-15 10:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-15  1:52 [PATCH] sysctl.c: Change a .proc_handler = proc_dointvec to &proc_dointvec, 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 [this message]
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
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=20091115103307.GB24931@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --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