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

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

[George Spelvin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Unser geliebter Führer schreib:
> sizeof without parenthesis is an abomination, and should never be used.

Huh.  I prefer sizeof without parens, like I prefer return without parens.

It actually annoys me when I see someone write

	return(0);

Because it's not a function (our language is too low-level to use
continuation-passing style), it's magic syntax.

Sizeof likewise.  I tend to use "p = malloc(sizeof *p)" a lot.
It just reads more nicely, to my eyes, than "p = malloc(sizeof(*p))".

If I wanted my code to be cluttered with parens, I'd write it in
Lots of Irritating Silly Parenthese.


Certainly, tha paren-less style is all over the kernel.  It's heavily
used in arch/x86/boot, for example.

I guess it's what you're used to.

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

[Linus Torvalds]

On Wed, Jul 11, 2012 at 1:14 AM, George Spelvin <linux@horizon.com> wrote:
>
> Huh.  I prefer sizeof without parens, like I prefer return without parens.

Umm. The two have *nothing* to do with each other.

> It actually annoys me when I see someone write
>
>         return(0);

Absolutely. Anybody who does that is just terminally confused.
"return()" is in no way a function.

But "sizeof()" really *is* a function. It acts exactly like a function
of it's argument. There is no reason to not treat it that way. Sure,
the C standard *allows* you to not have parenthesis around an
expression argument, but you should treat that as the parsing oddity
it is, nothing more. There is zero reason not to have the parenthesis
there.

In contrast, "return" can never be part of an expression, and the
parenthesis never make any sense.

With "return", there's no precedence issues, for example.

With "sizeof()" there are: sizeof(x)+1 is very different from
sizeof(x+1), and having the parenthesis there make it clearer for
everybody (sure, you can write the first one as "sizeof x + 1", but
let's face it, the precedence is way more obvious if you just think of
sizeof as a function).

Here's an example of a really bad use of "sizeof" that doesn't have
the parenthesis around the argument: sizeof(*p)->member. Quite
frankly, if you do this, you should be shot. It makes people have to
parse the C precedence rules by hand. In contrast, parsing
sizeof((*p)->member) is *way* easier for humans.

And let's face it: if you write your code so that it's easy to parse
for a machine, and ignore how easy it is to parse for a human, I don't
want you writing kernel code. There's a reason we have the coding
standards. They aren't for the *compiler*. They are for *humans*.

And humans should think of sizeof() as a function, not as some
ass-backwards special case C parsing rule that is subtle as hell.

                  Linus