Re: [2.6.29-rc2-git2] compilation warnings

[Takashi Iwai <tiwai@suse.de>]

At Tue, 27 Jan 2009 12:16:31 +0100,
Ingo Molnar wrote:
> 
> 
> * Takashi Iwai <tiwai@suse.de> 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