From: "Michael S. Tsirkin" <mst@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH 08/15] blkdebug: fix enum comparison'
Date: Mon, 6 Sep 2010 00:00:36 +0300 [thread overview]
Message-ID: <20100905210035.GA5423@redhat.com> (raw)
In-Reply-To: <AANLkTikMMTnr4KUpcc05hxiqPj-6Yzpv70hZW8u1rzJN@mail.gmail.com>
On Sun, Sep 05, 2010 at 07:37:54PM +0000, Blue Swirl wrote:
> On Sun, Sep 5, 2010 at 5:57 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Sun, Sep 05, 2010 at 03:06:32PM +0000, Blue Swirl wrote:
> >> The signedness of enum types depend on the compiler implementation.
> >> Therefore the check for negative values may or may not be meaningful.
> >>
> >> Fix by explicitly casting to a signed integer.
> >>
> >> Since the values are also checked earlier against event_names
> >> table, this is an internal error. Change the 'if' to 'assert'.
> >>
> >> This also fixes a warning with GCC flag -Wtype-limits.
> >>
> >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
> >> ---
> >> block/blkdebug.c | 4 +---
> >> 1 files changed, 1 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/block/blkdebug.c b/block/blkdebug.c
> >> index 2a63df9..4d6ff0a 100644
> >> --- a/block/blkdebug.c
> >> +++ b/block/blkdebug.c
> >> @@ -439,9 +439,7 @@ static void blkdebug_debug_event(BlockDriverState
> >> *bs, BlkDebugEvent event)
> >> struct BlkdebugRule *rule;
> >> BlkdebugVars old_vars = s->vars;
> >>
> >> - if (event < 0 || event >= BLKDBG_EVENT_MAX) {
> >> - return;
> >> - }
> >> + assert((int)event >= 0 && event < BLKDBG_EVENT_MAX);
> >
> > I am not sure all compilers must generate a negative value from
> > a very large unsigned integer cast to int.
>
> The enum rules seem to be vague. The type of enums may also be signed
> (on GCC when the enum set includes negative values, on other compilers
> in other cases). Do any machines or compilers exist (on which QEMU
> runs) where this could happen?
I remember reading that GCC sometimes assumes signed integers don't overflow,
and generates code behaves incorrectly if they do.
No idea whether this is ever the case for casts.
--
MST
prev parent reply other threads:[~2010-09-05 21:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 15:06 [Qemu-devel] [PATCH 08/15] blkdebug: fix enum comparison Blue Swirl
2010-09-05 17:57 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-05 19:37 ` Blue Swirl
2010-09-05 21:00 ` Michael S. Tsirkin [this message]
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=20100905210035.GA5423@redhat.com \
--to=mst@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/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.