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@xxxxxxxxxxxx>
>
> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
