Re: [2.6.29-rc2-git2] compilation warnings

From: Takashi Iwai
Date: Tue Jan 27 2009 - 06:50:31 EST


At Tue, 27 Jan 2009 12:16:31 +0100,
Ingo Molnar wrote:
>
>
> * Takashi Iwai <tiwai@xxxxxxx> wrote:
>
> > At Tue, 27 Jan 2009 09:46:28 +0100,
> > Jean Delvare wrote:
> > >
> > > On Tue, 27 Jan 2009 08:32:17 +0100, Takashi Iwai wrote:
> > > > At Tue, 27 Jan 2009 08:15:29 +0100,
> > > > Rufus & Azrael wrote:
> > > > >
> > > > > Here are my compilation warnings for fresh 2.6.29-rc2-git2 kernel :
> > > > >
> > > > > > sound/pci/hda/hda_codec.c: In function âget_empty_pcm_deviceâ:
> > > > > > sound/pci/hda/hda_codec.c:2544: attention : âdevâ may be used
> > > > > > uninitialized in this function
> > > >
> > > > A bogus warning. Ignore this.
> > >
> > > No matter how bogus it is, it should be fixed. Otherwise this is
> > > wasting the time of users and developers over and over again.
> >
> > Well, it's a bug of gcc appearing only in a certain version, so most
> > people won't see it.
> >
> > Of course, we can put uninitialized_var(). But, I don't basically like
> > adding it unconditionally...
>
> People will again and again look at this warning and waste time deciding
> that "it's a bogus warning" or even report it. As time goes on does the
> human cost get larger, linearly.
>
> Furthermore, if everyone in the kernel behaves like that we'll literally
> have dozens (even hundreds) of build warnings that might be bogus but
> which also obscure other, real warnings by their sheer mass.

The question is rather how often it's really seen.
I've tested 4 different gcc versions and a couple of other versions
with cross compiling occasionally, and this warning doesn't appear on
any versions.

> The cost of you adding a oneliner annotation is miniscule compared to that
> and it is a one-time effort. We already spent more energy on discussing
> this than it would have taken you to annotate it. Please.

Well, did we get a consensus about this? If yes, I'll follow it, of
course.

Adding uninitialized_var() essentially means to disable the check,
thus a new real bug in future might be overlooked. This is a bigger
drawback if it's just a warning that appears in only one old buggy gcc
version.

That's why I wrote "adding it *unconditionally*". If the warning
appears in many gcc versions, it's worth to hide.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/