From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 20:58:05 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9524C1065673; Sun, 6 Nov 2011 20:58:05 +0000 (UTC) Date: Sun, 6 Nov 2011 20:58:05 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111106205805.GA78142@freebsd.org> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB6F38E.2080006@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 20:58:05 -0000 On Sun Nov 6 11, Dimitry Andric wrote: > On 2011-11-06 21:33, Alexander Best wrote: > ... > > the problem is, something like > > > > uint x; > > > > if (x < 0) ... > > > > clang will warn about this, yet it is 100% valid code so my vote would be to > > make such an error into a warning. > > Sorry, but checking something unsigned to be smaller than zero is bogus, > or at the least superfluous, and it's perfectly sane to warn about this, > especially since the compiler is not going to emit code for it at all. there was a discussion with the topic "disable -Wtautological-compare for clang" on freebsd-toolchain@ and most of the devs considered this code *not* to be bogus. ;) > > The only time when this sort of check could be relevant, is when you are > using a typedef'd type, and you have no way to be sure if the type is > signed or unsigned. But then you will be in for trouble anyway... > > > ... > > the same with > > > > int x; > > > > x = x; > > > > i believe in both cases clang is too picky. > > This is a often-used idiom for attempting to 'shut up' a compiler when > it (quite legitimately) complains about unused variables or arguments. > > However, a better idiom is: > > (void) x; > > but even this can lead some compilers or analysis tools to complain > about "statements that don't do anything". A better way is to provide > UNUSED_VARIABLE and UNUSED_ARGUMENT macros, and handle shutting up the > compiler in its specific way there. > > Of course, the best solution is to just eliminate the unused variables > or arguments. If that is not possible, for example due to a function > signature that cannot be changed because of API considerations, you can > always use __unused attributes. i see. does PR #162321 fall into this category, or can the assignment be removed? cheers. alex