From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derek M Jones Subject: Re: [PATCH 7/7] asm-generic: suppress sparse warning in ioctl.h Date: Fri, 04 Apr 2008 15:08:01 +0100 Message-ID: <47F63641.4090103@knosof.co.uk> References: <1207182818.5740.26.camel@brick> <20080403013420.GV9785@ZenIV.linux.org.uk> <20080403024117.GZ9785@ZenIV.linux.org.uk> <47F53E84.8080607@freedesktop.org> <20080404011951.GC9785@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from queueout02-winn.ispmail.ntl.com ([81.103.221.56]:19272 "EHLO queueout02-winn.ispmail.ntl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759349AbYDDOad (ORCPT ); Fri, 4 Apr 2008 10:30:33 -0400 In-Reply-To: <20080404011951.GC9785@ZenIV.linux.org.uk> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Al Viro Cc: Josh Triplett , Linus Torvalds , Harvey Harrison , Andrew Morton , LKML , linux-sparse@vger.kernel.org Al, > * typedef *can* be variably-modified, but only in block scope. > Warning: this can get sticky for us - all sizes are evaluated when > typedef is reached. IOW, > typedef int a[n]; > a x; > if (n++ == 5) { > a y; > int z[n]; > } > will have size of y equal to that of x, but *not* equal to that of z. An opportunity for Sparse to issue a warning :-) > Another thing to keep in mind is that sizeof(VLA) is not a constant > expression *and* that sizeof argument is evaluated. IOW, not only > sizeof(int [n = f()]) > has side effects, but in > int (*p)[n]; > ... > sizeof(*(g(), p)) > will have g() evaluated. Note that if p had been declared as > int (*p)[4]; > the same sizeof() would *NOT* have called anything. This, BTW, is where > the rules for what an integer constant expression is are getting bloody > important: Any side effect appearing in a sizeof operand ought to be flagged. There are people out there who think that the side effects occur (even in C90). Sentence 1122: http://c0x.coding-guidelines.com/6.5.3.4.html "If the type of the operand is a variable length array type, the operand is evaluated;" But watch out for sentence 1584: http://c0x.coding-guidelines.com/6.7.5.2.html "Where a size expression is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator, it is unspecified whether or not the size expression is evaluated." > int n = 1; > int f(void) > { > int (*p)[1 + (0 && n)]; > return sizeof(*(g(), p)); > } > > _must_ call g() according to C99, while the same with > enum {n = 1;} must not, even though n won't be even looked at in either > case *and* any sane compiler will find return value of f() at compile > time, turning it to Any sane compiler that performs the analysis needed to deduce that the expression inside the parenthesis always evaluated to zero will turn it into.... > One more thing: use of sizeof(variably-modified type) may or may not > evaluate size expressions in there if they do not affect the result. > IOW, it's unspecified whether > sizeof(int (*)[n++]) > increments n; different compilers are broken in different ways and it This language feature came about because at least one vendor on the WG14 committee had a compiler that optimized away subexpressions within a sizeof that did not contribute to the result of the evaluation. My attempt to stop the behavior being unspecified did not succeed :-( -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek@knosof.co.uk Applications Standards Conformance Testing http://www.knosof.co.uk