[alsa-devel] [PATCH 5/5] ASoC: fix uninitialized variable warning

[Takashi Iwai]

At Wed, 4 Aug 2010 10:02:24 +0100,
Mark Brown wrote:
> 
> On Tue, Aug 03, 2010 at 03:20:26PM -0400, Bill Pemberton wrote:
> > quiet the warning about use of uninitialized fll_div in
> > wm8900_set_fll.  fll_div is initialized by fll_factors()
> 
> > Signed-off-by: Bill Pemberton <wfp5p at virginia.edu>
> 
> Always remember to CC maintainers on patches as covered in SubmittingPatches.
> 
> >  sound/soc/codecs/wm8900.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/sound/soc/codecs/wm8900.c b/sound/soc/codecs/wm8900.c
> > index 5da17a7..f1840c6 100644
> > --- a/sound/soc/codecs/wm8900.c
> > +++ b/sound/soc/codecs/wm8900.c
> > @@ -746,7 +746,7 @@ static int wm8900_set_fll(struct snd_soc_codec *codec,
> >  	int fll_id, unsigned int freq_in, unsigned int freq_out)
> >  {
> >  	struct wm8900_priv *wm8900 = snd_soc_codec_get_drvdata(codec);
> > -	struct _fll_div fll_div;
> > +	struct _fll_div uninitialized_var(fll_div);
> >  	unsigned int reg;
> 
> No, just stomping over the variable to shut up the warning doesn't
> improve anything at all.  You need to make sure that the compiler can
> actually follow the control flow to see that the data is always
> initialised rather than disabling the check and missing any actual
> issues.
> 
> I rather suspect this is just a bug in your compiler's flow analysis,
> it's not showing up with GCC 4.3.3 on ARM for me.

Yes, the uninitialized_var() thing is rarely useful because most cases
are false-positive.  If such an initialization is really needed, often
it indicates the need of refactoring.

All the patches posted here look unnecessary, so I'd like to skip.


thanks,

Takashi