From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57834 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqL9r-0002bS-Mr for qemu-devel@nongnu.org; Tue, 31 Aug 2010 03:21:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqL9o-0002Nl-Mu for qemu-devel@nongnu.org; Tue, 31 Aug 2010 03:21:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4943) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqL9o-0002Nd-FU for qemu-devel@nongnu.org; Tue, 31 Aug 2010 03:21:24 -0400 Message-ID: <4C7CAD70.9030705@redhat.com> Date: Tue, 31 Aug 2010 09:21:20 +0200 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/14] gcc extra warning fixes References: <1283182547-26116-1-git-send-email-Jes.Sorensen@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kwolf@redhat.com, qemu-devel@nongnu.org On 08/30/10 21:25, Blue Swirl wrote: > On Mon, Aug 30, 2010 at 3:35 PM, wrote: >> From: Jes Sorensen >> >> Hi, >> >> I started building QEMU with some more aggressive error flags to see >> what dropped out. I started fixing up some of the cases, removing >> unused arguments to functions, comparisons of unsigned types against >> negative values etc. and a few other minor changes to avoid compiler >> warnings. > > If the patches make all such warnings disappear, you could also > consider the same approach as taken by > 7ccfb2eb5f9d91bdb4139cb420a3b5f8deb2f6e8 and > ac41a6206fe9e1506010cd0aa9cf56ed3b37ae19. > > If a GCC flag can be enabled, it should not be just -Wextra, because > that means different things on different GCC versions, so please check > also > a316e3788df2781fda119e801e9b3d753f89b752. The one GCC flag I think we should enable, and probably was the one that caught the most bugs in my patch set is this one: -Wtype-limits There was only one false positive with this flag in block/blkdebug.c where it bails on a < 0 comparison of an enum. enum doesn't seem to be defined to being signed or unsigned, but a quick cast in that case would make that single false positive go away. Cheers, Jes