Re: fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function

[Cong WANG]

2007/3/31, Adrian Bunk <bunk@xxxxxxxxx>:
> On Thu, Mar 29, 2007 at 11:16:39PM -0400, Kyle Moffett wrote:
> > On Mar 28, 2007, at 16:14:54, Andrew Morton wrote:
> > >On Wed, 28 Mar 2007 19:23:32 +0200 (CEST)
> > >Jiri Kosina <jikos@xxxxxxxx> wrote:
> > >
> > >>blockdev: bd_claim_by_kobject() could check value of unititalized
> > >>pointer
> > >>
> > >>Fixes this warning:
> > >>
> > >>fs/block_dev.c: In function `bd_claim_by_kobject':
> > >>fs/block_dev.c:953: warning: 'found' might be used uninitialized
> > >>in this function
> > >>
> > >>struct bd_holder *found is initialized only when bd_claim()
> > >>returns zero. If it returns nonzero, ptr stays uninitialized.
> > >>Later the value of the pointer is checked.
> > >
> > >that generates extra code and people get upset.
> > >
> > >One approach which we could ue in here is
> > >
> > >     struct bd_holder *found = found;  /* Suppress bogus gcc warning */
> >
> > Well, that would be correct except the warning is an actual kernel
> > bug.  Read Jiri's message (which you also quoted):
> > >struct bd_holder *found is initialized only when bd_claim() returns
> > >zero. If it returns nonzero, ptr stays uninitialized. Later the
> > >value of the pointer is checked.
> >
> > So in this case it has to be initialized to NULL or there's a
> > potential BUG() lurking.
>
>
> No, the code is correct and it's impossible that the variable ever gets
> read uninitialized.
>
> And BTW, i386 gcc 4.1 doesn't give me a warning for this.
> Toralf, which gcc version and architecture did you see this with?

I am also using i386 gcc 4.1.1, and I did receive many warnings of
such kind yesterday. I think we should fix them.

And the reason for the existence of such things is we just want to use
them for writing first instead of reading, thus ignore the
initialization.

--
So Dark The Con Of Man.
-
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/