* [Qemu-devel] [PATCH] Fix comparison which always returned false
@ 2010-06-15 21:03 Stefan Weil
2010-06-15 21:28 ` Anthony Liguori
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Stefan Weil @ 2010-06-15 21:03 UTC (permalink / raw)
To: QEMU Developers; +Cc: Anthony Liguori, Gleb Natapov
Comparing an 8 bit value with ~0 does not work as expected.
Replace ~0 by UINT8_MAX in comparison and also in assignment
(and fix coding style, too).
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
hw/hpet.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 0c80ee5..d5c406c 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -74,7 +74,7 @@ typedef struct HPETState {
uint8_t hpet_id; /* instance id */
} HPETState;
-struct hpet_fw_config hpet_cfg = {.count = ~0};
+struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
@@ -682,8 +682,10 @@ static int hpet_init(SysBusDevice *dev)
int i, iomemtype;
HPETTimer *timer;
- if (hpet_cfg.count == ~0) /* first instance */
+ if (hpet_cfg.count == UINT8_MAX) {
+ /* first instance */
hpet_cfg.count = 0;
+ }
if (hpet_cfg.count == 8) {
fprintf(stderr, "Only 8 instances of HPET is allowed\n");
--
1.5.6.5
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix comparison which always returned false
2010-06-15 21:03 [Qemu-devel] [PATCH] Fix comparison which always returned false Stefan Weil
@ 2010-06-15 21:28 ` Anthony Liguori
2010-06-16 0:27 ` Richard Henderson
2010-06-15 21:28 ` [Qemu-devel] " Jan Kiszka
2010-06-15 21:41 ` [Qemu-devel] " malc
2 siblings, 1 reply; 8+ messages in thread
From: Anthony Liguori @ 2010-06-15 21:28 UTC (permalink / raw)
To: Stefan Weil; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
On 06/15/2010 04:03 PM, Stefan Weil wrote:
> Comparing an 8 bit value with ~0 does not work as expected.
> Replace ~0 by UINT8_MAX in comparison and also in assignment
> (and fix coding style, too).
>
Because when the uint8_t gets promoted, it doesn't get zero filled. I'd
rather something a bit more obvious like HPET_INVALID_COUNT.
Regards,
Anthony Liguori
> Cc: Gleb Natapov<gleb@redhat.com>
> Cc: Anthony Liguori<aliguori@us.ibm.com>
> Signed-off-by: Stefan Weil<weil@mail.berlios.de>
> ---
> hw/hpet.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/hpet.c b/hw/hpet.c
> index 0c80ee5..d5c406c 100644
> --- a/hw/hpet.c
> +++ b/hw/hpet.c
> @@ -74,7 +74,7 @@ typedef struct HPETState {
> uint8_t hpet_id; /* instance id */
> } HPETState;
>
> -struct hpet_fw_config hpet_cfg = {.count = ~0};
> +struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>
> static uint32_t hpet_in_legacy_mode(HPETState *s)
> {
> @@ -682,8 +682,10 @@ static int hpet_init(SysBusDevice *dev)
> int i, iomemtype;
> HPETTimer *timer;
>
> - if (hpet_cfg.count == ~0) /* first instance */
> + if (hpet_cfg.count == UINT8_MAX) {
> + /* first instance */
> hpet_cfg.count = 0;
> + }
>
> if (hpet_cfg.count == 8) {
> fprintf(stderr, "Only 8 instances of HPET is allowed\n");
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] Re: [PATCH] Fix comparison which always returned false
2010-06-15 21:03 [Qemu-devel] [PATCH] Fix comparison which always returned false Stefan Weil
2010-06-15 21:28 ` Anthony Liguori
@ 2010-06-15 21:28 ` Jan Kiszka
2010-06-16 4:30 ` Gleb Natapov
2010-06-15 21:41 ` [Qemu-devel] " malc
2 siblings, 1 reply; 8+ messages in thread
From: Jan Kiszka @ 2010-06-15 21:28 UTC (permalink / raw)
To: Stefan Weil; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
Stefan Weil wrote:
> Comparing an 8 bit value with ~0 does not work as expected.
> Replace ~0 by UINT8_MAX in comparison and also in assignment
> (and fix coding style, too).
>
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: Anthony Liguori <aliguori@us.ibm.com>
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
> ---
> hw/hpet.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/hpet.c b/hw/hpet.c
> index 0c80ee5..d5c406c 100644
> --- a/hw/hpet.c
> +++ b/hw/hpet.c
> @@ -74,7 +74,7 @@ typedef struct HPETState {
> uint8_t hpet_id; /* instance id */
> } HPETState;
>
> -struct hpet_fw_config hpet_cfg = {.count = ~0};
> +struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>
> static uint32_t hpet_in_legacy_mode(HPETState *s)
> {
> @@ -682,8 +682,10 @@ static int hpet_init(SysBusDevice *dev)
> int i, iomemtype;
> HPETTimer *timer;
>
> - if (hpet_cfg.count == ~0) /* first instance */
> + if (hpet_cfg.count == UINT8_MAX) {
> + /* first instance */
> hpet_cfg.count = 0;
> + }
>
> if (hpet_cfg.count == 8) {
> fprintf(stderr, "Only 8 instances of HPET is allowed\n");
That makes me wonder why we need to signal this special value of
hpet_cfg.count to seabios at all. Why isn't plain 0 for no hpets
sufficient, Gleb?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix comparison which always returned false
2010-06-15 21:03 [Qemu-devel] [PATCH] Fix comparison which always returned false Stefan Weil
2010-06-15 21:28 ` Anthony Liguori
2010-06-15 21:28 ` [Qemu-devel] " Jan Kiszka
@ 2010-06-15 21:41 ` malc
2010-06-15 21:44 ` malc
2 siblings, 1 reply; 8+ messages in thread
From: malc @ 2010-06-15 21:41 UTC (permalink / raw)
To: Stefan Weil; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
On Tue, 15 Jun 2010, Stefan Weil wrote:
This should go in asap, it breaks PPC in quite visible and ugly way...
> Comparing an 8 bit value with ~0 does not work as expected.
> Replace ~0 by UINT8_MAX in comparison and also in assignment
> (and fix coding style, too).
>
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: Anthony Liguori <aliguori@us.ibm.com>
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
> ---
> hw/hpet.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/hpet.c b/hw/hpet.c
> index 0c80ee5..d5c406c 100644
> --- a/hw/hpet.c
> +++ b/hw/hpet.c
> @@ -74,7 +74,7 @@ typedef struct HPETState {
> uint8_t hpet_id; /* instance id */
> } HPETState;
>
> -struct hpet_fw_config hpet_cfg = {.count = ~0};
> +struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>
> static uint32_t hpet_in_legacy_mode(HPETState *s)
> {
> @@ -682,8 +682,10 @@ static int hpet_init(SysBusDevice *dev)
> int i, iomemtype;
> HPETTimer *timer;
>
> - if (hpet_cfg.count == ~0) /* first instance */
> + if (hpet_cfg.count == UINT8_MAX) {
> + /* first instance */
> hpet_cfg.count = 0;
> + }
>
> if (hpet_cfg.count == 8) {
> fprintf(stderr, "Only 8 instances of HPET is allowed\n");
>
--
mailto:av1474@comtv.ru
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix comparison which always returned false
2010-06-15 21:41 ` [Qemu-devel] " malc
@ 2010-06-15 21:44 ` malc
0 siblings, 0 replies; 8+ messages in thread
From: malc @ 2010-06-15 21:44 UTC (permalink / raw)
To: Stefan Weil; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
On Wed, 16 Jun 2010, malc wrote:
> On Tue, 15 Jun 2010, Stefan Weil wrote:
>
> This should go in asap, it breaks PPC in quite visible and ugly way...
Right... forgot something, DIY...
Thanks, applied.
[..snip..]
--
mailto:av1474@comtv.ru
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix comparison which always returned false
2010-06-15 21:28 ` Anthony Liguori
@ 2010-06-16 0:27 ` Richard Henderson
2010-06-16 12:34 ` Anthony Liguori
0 siblings, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2010-06-16 0:27 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
On 06/15/2010 02:28 PM, Anthony Liguori wrote:
> On 06/15/2010 04:03 PM, Stefan Weil wrote:
>> Comparing an 8 bit value with ~0 does not work as expected.
>> Replace ~0 by UINT8_MAX in comparison and also in assignment
>> (and fix coding style, too).
>>
>
> Because when the uint8_t gets promoted, it doesn't get zero filled. I'd
> rather something a bit more obvious like HPET_INVALID_COUNT.
Er, yes it does. The problem is that it *did* get zero-extended,
but ~0 is 0xffffffff, so the comparison fails.
But I really agree with Jan Kiszka down-thread -- why do we need
to signal this as a special case at all?
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] Re: [PATCH] Fix comparison which always returned false
2010-06-15 21:28 ` [Qemu-devel] " Jan Kiszka
@ 2010-06-16 4:30 ` Gleb Natapov
0 siblings, 0 replies; 8+ messages in thread
From: Gleb Natapov @ 2010-06-16 4:30 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Anthony Liguori, QEMU Developers
On Tue, Jun 15, 2010 at 11:28:42PM +0200, Jan Kiszka wrote:
> Stefan Weil wrote:
> > Comparing an 8 bit value with ~0 does not work as expected.
> > Replace ~0 by UINT8_MAX in comparison and also in assignment
> > (and fix coding style, too).
> >
> > Cc: Gleb Natapov <gleb@redhat.com>
> > Cc: Anthony Liguori <aliguori@us.ibm.com>
> > Signed-off-by: Stefan Weil <weil@mail.berlios.de>
> > ---
> > hw/hpet.c | 6 ++++--
> > 1 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/hpet.c b/hw/hpet.c
> > index 0c80ee5..d5c406c 100644
> > --- a/hw/hpet.c
> > +++ b/hw/hpet.c
> > @@ -74,7 +74,7 @@ typedef struct HPETState {
> > uint8_t hpet_id; /* instance id */
> > } HPETState;
> >
> > -struct hpet_fw_config hpet_cfg = {.count = ~0};
> > +struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
> >
> > static uint32_t hpet_in_legacy_mode(HPETState *s)
> > {
> > @@ -682,8 +682,10 @@ static int hpet_init(SysBusDevice *dev)
> > int i, iomemtype;
> > HPETTimer *timer;
> >
> > - if (hpet_cfg.count == ~0) /* first instance */
> > + if (hpet_cfg.count == UINT8_MAX) {
> > + /* first instance */
> > hpet_cfg.count = 0;
> > + }
> >
> > if (hpet_cfg.count == 8) {
> > fprintf(stderr, "Only 8 instances of HPET is allowed\n");
>
> That makes me wonder why we need to signal this special value of
> hpet_cfg.count to seabios at all. Why isn't plain 0 for no hpets
> sufficient, Gleb?
>
> Jan
>
I want bios to be able to distinguish between qemu that does not support
HPET cfg_fw and qemu that does. On the former bios should always create
HPET table for backwards compatibility.
--
Gleb.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix comparison which always returned false
2010-06-16 0:27 ` Richard Henderson
@ 2010-06-16 12:34 ` Anthony Liguori
0 siblings, 0 replies; 8+ messages in thread
From: Anthony Liguori @ 2010-06-16 12:34 UTC (permalink / raw)
To: Richard Henderson; +Cc: Anthony Liguori, QEMU Developers, Gleb Natapov
On 06/15/2010 07:27 PM, Richard Henderson wrote:
> On 06/15/2010 02:28 PM, Anthony Liguori wrote:
>
>> On 06/15/2010 04:03 PM, Stefan Weil wrote:
>>
>>> Comparing an 8 bit value with ~0 does not work as expected.
>>> Replace ~0 by UINT8_MAX in comparison and also in assignment
>>> (and fix coding style, too).
>>>
>>>
>> Because when the uint8_t gets promoted, it doesn't get zero filled. I'd
>> rather something a bit more obvious like HPET_INVALID_COUNT.
>>
> Er, yes it does. The problem is that it *did* get zero-extended,
> but ~0 is 0xffffffff, so the comparison fails.
>
Typo on my part. I meant one filled obviously.
Regards,
Anthony Liguori
> But I really agree with Jan Kiszka down-thread -- why do we need
> to signal this as a special case at all?
>
>
> r~
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-06-16 12:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-15 21:03 [Qemu-devel] [PATCH] Fix comparison which always returned false Stefan Weil
2010-06-15 21:28 ` Anthony Liguori
2010-06-16 0:27 ` Richard Henderson
2010-06-16 12:34 ` Anthony Liguori
2010-06-15 21:28 ` [Qemu-devel] " Jan Kiszka
2010-06-16 4:30 ` Gleb Natapov
2010-06-15 21:41 ` [Qemu-devel] " malc
2010-06-15 21:44 ` malc
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).