From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MLcIa-00007h-0h
	for qemu-devel@nongnu.org; Tue, 30 Jun 2009 08:18:56 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MLcIV-00004r-2n
	for qemu-devel@nongnu.org; Tue, 30 Jun 2009 08:18:55 -0400
Received: from [199.232.76.173] (port=45008 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MLcIU-0008WM-QP
	for qemu-devel@nongnu.org; Tue, 30 Jun 2009 08:18:50 -0400
Received: from mx2.redhat.com ([66.187.237.31]:49740)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1MLcIU-0004s0-4t
	for qemu-devel@nongnu.org; Tue, 30 Jun 2009 08:18:50 -0400
Date: Tue, 30 Jun 2009 15:16:13 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] move -Wno-error=uninitialized to configure
Message-ID: <20090630121613.GB1227@redhat.com>
References: <20090630113949.GA32364@redhat.com>
	<200906301309.27397.paul@codesourcery.com>
	<20090630121240.GA1227@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090630121240.GA1227@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

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.

-- 
MST