Re: [PATCH] kernel/fork.c: use sizeof() instead of sizeof

[Al Viro]

On Tue, Feb 02, 2016 at 03:56:01PM +0000, Aleksa Sarai wrote:

> I haven't looked at the order of operations for sizeof, but I imagine
> there's cases where it might bind in a different way than is expected. Are
> you sure there'd be no negative downside to removing the check (the whole
> point is to ensure no new code has stuff like that).

I won't comment on the whole point (or lack thereof) of checkpatch.pl, but
the only subtlety with sizeof is that sizeof ( type-name ) <something> is
*never* interpreted as sizeof of something cast to type-name.  IOW, its
priority is higher than that of typecasts.  If <something> starts with {,
it's a sizeof of compound literal, otherwise it's an unary expression
"sizeof ( type-name )" followed by <something>, which might or might not
yield a valid expression (e.g.
	sizeof(int)1
won't parse, while
	sizeof(int)-1
will be treated as (sizeof(int)) - 1).

Potential headache is along the lines of
#define A (int)-1
sizeof A
but that's more of "use enough parentheses in body of a macro to avoid nasty
surprises" - same as e.g.
#define A 2 + 2
A * A
yielding 8 (2 + 2 * 2 + 2) rather than expected 16 ((2 + 2) * (2 + 2))

FWIW, the actual rules are
	unary-expression: postfix-expression |
			  ++ unary-expression |
			  -- unary-expression |
			  - cast-expression |
			  + cast-expression |
			  ! cast-expression |
			  ~ cast-expression |
			  * cast-expression |
			  & cast-expression |
			  sizeof unary-expression |
			  sizeof ( type-name )
	cast-expression: unary-expression |
			 ( type-name ) cast-expression
Note that while e.g.
	++ ++ n
is allowed by grammar, it runs afoul of the constraint for ++ argument, which
must be a modifiable lvalue.  None of the operators above yield that, so
the rules for ++ and -- might as well have been ++ postfix-expression and
-- postfix-expression resp.