All of lore.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 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.