[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] move -Wno-error=uninitialized to configure
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH] move -Wno-error=uninitialized to configure |
Date: |
Tue, 30 Jun 2009 15:58:49 +0300 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
Re: [Qemu-devel] [PATCH] move -Wno-error=uninitialized to configure, Avi Kivity, 2009/06/30