All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Aloni <da-x@monatomic.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Kosina <jikos@jikos.cz>, Lee Revell <rlrevell@joe-job.com>,
	Toralf F?rster <toralf.foerster@gmx.de>,
	andrea@suse.de, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function
Date: Wed, 28 Mar 2007 23:59:07 +0200	[thread overview]
Message-ID: <20070328215907.GA28682@localdomain> (raw)
In-Reply-To: <20070328131454.cdb06bc3.akpm@linux-foundation.org>

On Wed, Mar 28, 2007 at 01:14:54PM -0700, 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
[..]
> > @@ -950,7 +950,7 @@ static int bd_claim_by_kobject(struct block_device *bdev, void *holder,
> >  				struct kobject *kobj)
> >  {
> >  	int res;
> > -	struct bd_holder *bo, *found;
> > +	struct bd_holder *bo, *found = NULL;
> 
> that generates extra code and people get upset.

I, for one, not upset. On the contrary.

IMHO gcc should be smart enough to optimize that code properly with that 
"= NULL" added. 

BTW with gcc 4.1.2 on x86_64 that warning doesn't get emitted, and it 
generates the same exact code with or without " = NULL". One could aruge,
if people are upset about more code being generated because they use an 
older stable branch of gcc, it's _their_ problem.

> 	struct bd_holder *found;
> 
> 	squash_bogus_uninit_warning(found);	/* useful comment goes here */
> 
> which is also unpleasant, but not as unpleasant as a screenful of warnings
> which hide real problems, IMO.

If there was such 'squash_bogus_uninit_warning' macro exist and in use,
then this could have been a possible scenario:

  A) There's some 200-lines long function.
  B) It has a squash_bogus_uninit_warning() somewhere in the beginning.
  C) Someone commits a patch that uses an uninitialized variable on _some_
     cases and it doesn't generate a warning.
  D) You get an 'heisenbug', since that pointer might point to something
     that is dereferencable without a fault, etc.

I think that warnings of these kind (assuming that they are not generated
as a result of deficiencies in the latest stable version of gcc) exist
for a damn good reason - the code should be fixed and that warning 
shouldn't be bypassed in semi-nasty ways.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

  reply	other threads:[~2007-03-28 21:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28 16:47 fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function 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 [this message]
2007-03-30  3:16       ` Kyle Moffett
2007-03-30 19:47         ` Adrian Bunk
2007-03-31  3:09           ` Cong WANG
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=20070328215907.GA28682@localdomain \
    --to=da-x@monatomic.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrea@suse.de \
    --cc=jikos@jikos.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=toralf.foerster@gmx.de \
    --cc=viro@zeniv.linux.org.uk \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.