From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLcxn-0006ta-IL for qemu-devel@nongnu.org; Tue, 30 Jun 2009 09:01:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLcxi-0006sf-UI for qemu-devel@nongnu.org; Tue, 30 Jun 2009 09:01:30 -0400 Received: from [199.232.76.173] (port=58917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLcxi-0006sZ-Qq for qemu-devel@nongnu.org; Tue, 30 Jun 2009 09:01:26 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46993) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLcxi-0005Ih-72 for qemu-devel@nongnu.org; Tue, 30 Jun 2009 09:01:26 -0400 Date: Tue, 30 Jun 2009 15:58:49 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] move -Wno-error=uninitialized to configure Message-ID: <20090630125849.GA10413@redhat.com> References: <20090630113949.GA32364@redhat.com> <20090630121240.GA1227@redhat.com> <20090630121613.GB1227@redhat.com> <200906301346.38466.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906301346.38466.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Laurent Desnogues , Anthony Liguori , qemu-devel@nongnu.org On Tue, Jun 30, 2009 at 01:44:31PM +0100, Paul Brook wrote: > On Tuesday 30 June 2009, Michael S. Tsirkin wrote: > > On Tue, Jun 30, 2009 at 03:12:40PM +0300, Michael S. Tsirkin wrote: > > > On Tue, Jun 30, 2009 at 01:07:34PM +0100, Paul Brook wrote: > > > > On Tuesday 30 June 2009, Michael S. Tsirkin wrote: > > > > > Move -Wno-error=uninitialized out of rules.mak and into configure. > > > > > Only use it if supported by compiler. > > > > > > > > Why? Shouldn't we be fixing the uninitialized variables? > > > > > > > > Paul > > > > > > gcc's algorithm for detecting uninitialized variables is > > > famously unreliable. Just scattering '= 0' around the code > > > masks the warning but hides the fact that application logic > > > might still be broken. > > > > To clarify: what's broken is that gcc has false positives in the logic. > > And if you work around this by adding initialization where it's not > > really required, you confuse other tools that would otherwise have a > > chance to detect an error. > > In that case should we be using -Wno-uninitialized? > > The whole point of -Werror is that it forces us to keep the code clean. > Having to mentally filter out false positives just doesn't work. Once you have > routinely expected warnings then people stop checking for new ones. > > Paul That's what -Wno-error=uninitialized does: makes the filtering automatically so you don't need to filter it mentally. -- MST