LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Cong WANG" <xiyou.wangcong@gmail.com>
To: "Adrian Bunk" <bunk@stusta.de>,
	linux-kernel@vger.kernel.org, jikos@jikos.cz,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function
Date: Sat, 31 Mar 2007 11:09:03 +0800	[thread overview]
Message-ID: <2375c9f90703302009i28f2f11ayf3e83216f4017c7d@mail.gmail.com> (raw)
In-Reply-To: <20070330194701.GL14134@stusta.de>

2007/3/31, Adrian Bunk <bunk@stusta.de>:
> 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@jikos.cz> 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.

  reply	other threads:[~2007-03-31  3:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28 16:47 Toralf Förster
2007-03-28 16:56 ` Lee Revell
2007-03-28 17:23   ` Jiri Kosina
2007-03-28 20:14     ` Andrew Morton
2007-03-28 21:59       ` Dan Aloni
2007-03-30  3:16       ` Kyle Moffett
2007-03-30 19:47         ` Adrian Bunk
2007-03-31  3:09           ` Cong WANG [this message]
2007-03-31  8:11           ` Toralf Förster
2007-03-31 14:04             ` Adrian Bunk
2007-03-30 19:40   ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2375c9f90703302009i28f2f11ayf3e83216f4017c7d@mail.gmail.com \
    --to=xiyou.wangcong@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@stusta.de \
    --cc=jikos@jikos.cz \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: fs/block_dev.c:953: warning: '\''found'\'' might be used uninitialized in this function' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).