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 functionof it's argument. There is no reason to not treat it that way. Sure,the C standard *allows* you to not have parenthesis around anexpression argument, but you should treat that as the parsing oddityit is, nothing more. There is zero reason not to have the parenthesisthere.

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

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

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

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

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

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