linux-kernel - Re: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

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]

Date:	Mon, 9 Jul 2012 19:28:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Joe Perches <joe@...ches.com>, 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, Jul 9, 2012 at 6:50 PM, David Rientjes <rientjes@...gle.com> wrote:
>
> This doesn't suggest parenthesis for sizeof at all times

sizeof without parenthesis is an abomination, and should never be used.

Sure, you don't need to have the parenthesis (except when you do - for
actual types), but it's a parsing oddity.

The sane solution is: just add the f*cking parenthesis, and don't use
the parsing oddity.

The parenthesis are *required* when it is a type, and they are a nice
clarification (and makes the code easier to read) when it's an
expression. Not having them is insane, because it just makes it clear
how odd the parsing rules are for the two different cases.

And talking about "prefix operators" is a moronic thing to do. It does
*not* look like a prefix operator, and it does not even *act* like a
prefix operator (look at types, where it really does require the
parenthesis). But most importantly, it's not how sane people think
about it.

Think of it as a function, and get over your idiotic pissing match
over how long you've both known C. That's irrelevant. It's a C builtin
function with (unnecessarily) odd parsing rules that the kernel tries
to standardize. The fact that it can take a type is the least odd part
of it (there are other built-in C extensions that look like functions
and do special things with the arguments they get -
__builtin_constant_p(), __builtin_choose_expr() etc - they don't
evaluate the *value* of the argument either).

Btw, the spacing rule is separate, and the "3.1 Spaces" thing was
added later and is in fact somewhat misleading. The spacing rules have
nothing to do with "function-vs-keyword", and everything to do with
"function-vs-control-flow". So "sizeof()" is not actually an exception
at all, like the docs state: it's perfectly regular. It looks and acts
as a function, not as a control flow operation.

What makes if/while/else/do/for stand out is that they are the native
C control flow operators, and they have spaces around them. They fact
that they are keywords is irrelevant. OF COURSE they are keywords,
since they are the native control flow ops, but that is not why they
have special spacing rules. The reason they have special spacing rules
is that

    for (x; y; z) {

is a control flow construct, while

    function(x, y, z);

is just a normal function expression. And in *no* case do we put
spaces after the parenthesis, we do it after the comma (or semicolon
for "for (a; b; c)").

We do have some control flow macros ("list_for_each()" etc), and they
could logically have the space, but hey, they are also normal macros,
so whatever. The kernel special-cases the native control-flow stuff,
not the random control flow macro oddities we've created for special
occasions.

                Linus
--
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/