mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesper Juhl <jesper.juhl@gmail.com>
To: Jens Axboe <axboe@suse.de>
Cc: Khushil Dep <khushil.dep@help.basilica.co.uk>,
	Al Viro <viro@ftp.linux.org.uk>,
	Luiz Fernando Capitulino <lcapitulino@mandriva.com.br>,
	akpm <akpm@osdl.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bio: gcc warning fix.
Date: Fri, 6 Jan 2006 19:53:15 +0100	[thread overview]
Message-ID: <9a8748490601061053q48a9968emb39cc8dcdaad11c3@mail.gmail.com> (raw)
In-Reply-To: <20060106184810.GR3389@suse.de>

On 1/6/06, Jens Axboe <axboe@suse.de> wrote:
> On Fri, Jan 06 2006, Jesper Juhl wrote:
> > gcc is right to warn in the sense that it doesn't know if
> > bvec_alloc_bs() will read or write into idx when its address is passed
>
> The function is right there, on top of bio_alloc_bioset(). It's even
> inlined. gcc has absolutely no reason to complain.
>
Right, gcc should be smarter in that case... hmm, I wonder if it warns
if you build with -funit-at-a-time ...

> > to it. But since we know that bvec_alloc_bs() only reads from it after
>
> bio_alloc_bioset() you mean.
>
Actually I did mean that bvec_alloc_bs() only reads the value of *idx
after it has assigned a value to it, but ofcourse there's no way for
gcc to warn about the use inside that function since there it has to
assume that whatever value of the variable being passed as a pointer
is the intended one.
Of course bio_alloc_bioset() also only reads from idx after
bvex_alloc_bs() has initialized it which is why the warning is bogus.

> > having assigned a value we know that gcc's warning is wrong, idx can
> > never *actually* be used uninitialized.
>
> Indeed, that's the whole point. For the original submitter, you are not
> the first to submit this. See archives for basically the same thread as
> this one...
>
> --
> Jens Axboe
>
>

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

  reply	other threads:[~2006-01-06 18:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-06 15:48 Khushil Dep
2006-01-06 18:41 ` Jesper Juhl
2006-01-06 18:48   ` Jens Axboe
2006-01-06 18:53     ` Jesper Juhl [this message]
2006-01-06 18:58     ` Luiz Fernando Capitulino
2006-01-06 19:04       ` Jens Axboe
2006-01-06 19:05       ` Jesper Juhl
2006-01-06 19:33     ` Zan Lynx
2006-01-06 19:56       ` Al Viro
2006-01-07 12:22         ` Peter Osterlund
  -- strict thread matches above, loose matches on Subject: below --
2006-01-06 15:07 Luiz Fernando Capitulino
2006-01-06 15:28 ` Jens Axboe
2006-01-06 15:39 ` Al Viro
2006-01-06 22:43   ` Daniel Barkalow
2006-01-06 22:52     ` Jesper Juhl
2006-01-06 23:13       ` Daniel Barkalow

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=9a8748490601061053q48a9968emb39cc8dcdaad11c3@mail.gmail.com \
    --to=jesper.juhl@gmail.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=khushil.dep@help.basilica.co.uk \
    --cc=lcapitulino@mandriva.com.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®