From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933519AbcBBRES (ORCPT ); Tue, 2 Feb 2016 12:04:18 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:59298 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932726AbcBBREQ (ORCPT ); Tue, 2 Feb 2016 12:04:16 -0500 Date: Tue, 2 Feb 2016 17:04:06 +0000 From: Al Viro To: Aleksa Sarai Cc: xypron.glpk@gmx.de, Tejun Heo , koct9i@gmail.com, ebiederm@xmission.com, Wei Tang , linux-kernel@vger.kernel.org, oleg@redhat.com, josh@joshtriplett.org, jason.low2@hp.com, peterz@infradead.org, Ingo Molnar , akpm@linux-foundation.org, kirill.shutemov@linux.intel.com Subject: Re: [PATCH] kernel/fork.c: use sizeof() instead of sizeof Message-ID: <20160202170406.GP17997@ZenIV.linux.org.uk> References: <1454399594-14307-1-git-send-email-tangwei@cmss.chinamobile.com> <20160202091118.GB30393@gmail.com> <20160202154531.GO17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ) is *never* interpreted as sizeof of something cast to type-name. IOW, its priority is higher than that of typecasts. If starts with {, it's a sizeof of compound literal, otherwise it's an unary expression "sizeof ( type-name )" followed by , 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.