From: Joe Perches <joe@perches.com>
To: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, mm-commits@vger.kernel.org,
apw@canonical.com
Subject: Re: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree
Date: Mon, 09 Jul 2012 19:03:22 -0700 [thread overview]
Message-ID: <1341885802.6118.101.camel@joe2Laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1207091834230.20591@chino.kir.corp.google.com>
On Mon, 2012-07-09 at 18:50 -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, Joe Perches wrote:
>
> > CodingStyle already does suggest parenthesis around sizeof
> >
> > 3.1: Spaces
> >
> > Linux kernel style for use of spaces depends (mostly) on
> > function-versus-keyword usage. Use a space after (most) keywords. The
> > notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
> > somewhat like functions (and are usually used with parentheses in Linux,
> > although they are not required in the language, as in: "sizeof info" after
> > "struct fileinfo info;" is declared).
> >
> > So use a space after these keywords:
> > if, switch, case, for, do, while
> > but not with sizeof, typeof, alignof, or __attribute__. E.g.,
> > s = sizeof(struct file);
> >
>
> This doesn't suggest parenthesis for sizeof at all times,
Depends on interpretation. Linus' email from 2008 is pretty clear.
> it's saying that
> Linux doesn't use the gcc, glibc, C99 way of doing "sizeof (struct file)"
> for type names as I've already said three times and rather prefers
> "sizeof(struct file)". That's fine.
>
> I'm talking about the C99 specification that says the sizeof operator act
> on unary expressions, i.e. not type names that you keep talking about and
> apparently don't understand the difference between. Casts are done with
> type names, you can't do "unsigned long ptr", you do "(unsigned long)ptr".
> Sizeof operators using type names do the same thing:
> "sizeof (unsigned long)". The space is just a stylistic difference.
>
> You may not understand the difference between a type and a unary
> expression, but other C programmers do, i.e. those who have implemented
> the over 1000 places in the kernel that already do this because they
> learned from K&R.
I don't really care what style a large block of code
uses. I care that it mostly has the same form.
fyi: I learned C from K&R and Bill Joy in the mid 70's.
> I guarantee you that those who learned from K&R don't
> think sizeof(unsigned long) "looks like a function".
Tell that to Linus. He wrote the email I referenced
which you so apparently blithely elided.
Repeating it:
"Another example of this is "sizeof". The kernel universally (I hope) has
parenthesis around the sizeof argument, even though it's clearly not
required by the C language."
> And typeof is a gnu extension, it's not part of the C99 standard.
Irrelevant as Linux uses it.
> You realize your patch doesn't catch kmalloc(sizeof *p, ...) since it's
> checking for lval and the unary operator '*' is not considered part of an
> identifier, right?
Oh look, useful feedback instead of useless carping about
how much I know or don't know c.
> Perhaps you should propose a patch that actually works
> first because yours is busted.
I have one here. I'll forward it soonish.
next prev parent reply other threads:[~2012-07-10 2:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120709215256.9A4F71E0043@wpzn4.hot.corp.google.com>
2012-07-09 22:23 ` + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree David Rientjes
2012-07-09 22:36 ` Joe Perches
2012-07-09 22:55 ` David Rientjes
2012-07-09 23:21 ` Joe Perches
2012-07-09 23:47 ` David Rientjes
2012-07-10 0:55 ` Joe Perches
2012-07-10 1:50 ` David Rientjes
2012-07-10 2:03 ` Joe Perches [this message]
2012-07-10 2:21 ` David Rientjes
2012-07-10 5:12 ` Joe Perches
2012-07-10 2:28 ` Linus Torvalds
2012-07-10 2:49 ` David Rientjes
2012-07-12 5:23 ` [PATCH V2] checkpatch: Add check for use of sizeof without parenthesis Joe Perches
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=1341885802.6118.101.camel@joe2Laptop \
--to=joe@perches.com \
--cc=apw@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox