lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1341885802.6118.101.camel@joe2Laptop>
Date:	Mon, 09 Jul 2012 19:03:22 -0700
From:	Joe Perches <joe@...ches.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org,
	apw@...onical.com
Subject: Re: +
 checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to
 -mm tree

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ