Patchwork Remove typedef for bool from eepro100.c

login
register
mail settings
Submitter Amit Shah
Date Aug. 27, 2009, 12:31 p.m.
Message ID <1251376284-22426-1-git-send-email-amit.shah@redhat.com>
Download mbox | patch
Permalink /patch/32251/
State Superseded
Headers show

Comments

Amit Shah - Aug. 27, 2009, 12:31 p.m.
eepro100.c shouldn't have the need to do this in its local header file.

And I recently started getting this:

$ make -j3
...
  CC    x86_64-softmmu/eepro100.o
/home/amit/src/qemu/hw/eepro100.c:112: error: two or more data types
in declaration specifiers
/home/amit/src/qemu/hw/eepro100.c:112: warning: useless type name in
empty declaration
make[1]: *** [eepro100.o] Error 1

so just remove the typedef and include <stdbool.h> instead.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 hw/eepro100.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)
Reimar Döffinger - Aug. 27, 2009, 12:45 p.m.
On Thu, Aug 27, 2009 at 06:01:24PM +0530, Amit Shah wrote:
> eepro100.c shouldn't have the need to do this in its local header file.
> 
> And I recently started getting this:
> 
> $ make -j3
> ...
>   CC    x86_64-softmmu/eepro100.o
> /home/amit/src/qemu/hw/eepro100.c:112: error: two or more data types
> in declaration specifiers
> /home/amit/src/qemu/hw/eepro100.c:112: warning: useless type name in
> empty declaration
> make[1]: *** [eepro100.o] Error 1
> 
> so just remove the typedef and include <stdbool.h> instead.
> 
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
> ---
>  hw/eepro100.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index 8988b3f..0634f8c 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -38,6 +38,7 @@
>  #endif
>  
>  #include <stddef.h>             /* offsetof */
> +#include <stdbool.h>
>  #include "hw.h"
>  #include "pci.h"
>  #include "net.h"
> @@ -109,8 +110,6 @@
>  #define INT_MASK        0x0100
>  #define DRVR_INT        0x0200  /* Driver generated interrupt. */
>  
> -typedef unsigned char bool;
> -

I doubt it matters much, but
1) stdbool bool is probably 4 bytes, not just 1 like char
2) all assignments to bool variable are converted to 0/1 which could
make a speed difference (not here since the code actually does that
explicitly).
3) is stdbool.h available everywhere where qemu is supposed to compile?

I suggest to just get rid of bool in this file, it is only used in 5
places, i.e. change
>        bool bit_el = ((command & 0x8000) != 0);
to
>        int bit_el = command & 0x8000;
Laurent Desnogues - Aug. 27, 2009, 2 p.m.
On Thu, Aug 27, 2009 at 2:45 PM, Reimar
Döffinger<Reimar.Doeffinger@gmx.de> wrote:
> 1) stdbool bool is probably 4 bytes, not just 1 like char

It's one byte on my gcc 4.4.0.

> I suggest to just get rid of bool in this file, it is only used in 5
> places, i.e. change
>>        bool bit_el = ((command & 0x8000) != 0);
> to
>>        int bit_el = command & 0x8000;

This is dangerous if you start using bit_el in integer expressions
by accident (for instance using & or |).


Laurent
Reimar Döffinger - Aug. 27, 2009, 2:42 p.m.
On Thu, Aug 27, 2009 at 04:00:17PM +0200, Laurent Desnogues wrote:
> On Thu, Aug 27, 2009 at 2:45 PM, Reimar
> Döffinger<Reimar.Doeffinger@gmx.de> wrote:
> > 1) stdbool bool is probably 4 bytes, not just 1 like char
> 
> It's one byte on my gcc 4.4.0.
> 
> > I suggest to just get rid of bool in this file, it is only used in 5
> > places, i.e. change
> >>        bool bit_el = ((command & 0x8000) != 0);
> > to
> >>        int bit_el = command & 0x8000;
> 
> This is dangerous if you start using bit_el in integer expressions
> by accident (for instance using & or |).

Programming errors are dangerous in general. I don't see much of a point
of cluttering the code with not really effective ways to hide their
effects (unless  you wanted to suggest using "bool bit_el = command & 0x8000;",
I see that bool is already used in some places in qemu and performance
doesn't matter here so it indeed shouldn't be a problem).
Jamie Lokier - Aug. 27, 2009, 2:59 p.m.
Reimar Döffinger wrote:
> On Thu, Aug 27, 2009 at 04:00:17PM +0200, Laurent Desnogues wrote:
> > On Thu, Aug 27, 2009 at 2:45 PM, Reimar
> > Döffinger<Reimar.Doeffinger@gmx.de> wrote:
> > > 1) stdbool bool is probably 4 bytes, not just 1 like char
> > 
> > It's one byte on my gcc 4.4.0.
> > 
> > > I suggest to just get rid of bool in this file, it is only used in 5
> > > places, i.e. change
> > >>        bool bit_el = ((command & 0x8000) != 0);
> > > to
> > >>        int bit_el = command & 0x8000;
> > 
> > This is dangerous if you start using bit_el in integer expressions
> > by accident (for instance using & or |).
> 
> Programming errors are dangerous in general. I don't see much of a
> point of cluttering the code with not really effective ways to hide
> their effects (unless you wanted to suggest using "bool bit_el =
> command & 0x8000;", I see that bool is already used in some places
> in qemu and performance doesn't matter here so it indeed shouldn't
> be a problem).

I've seen the "int flag = (x & FLAG); if (flag & otherflag)" bug
enough times to consider it one of those subtle things that
programmers don't notice easily.

A variation is "long flag = (x & FLAG); ... function(flag)" where
"function" takes an int argument and FLAG doesn't fit.  Or just "int
flag = (x & FLAG)".

My approach is to use "!= 0" if I think the variable really is
boolean, and only keep the original masked bit pattern if it's clear
in context that the variable is supposed to contain a bit pattern.

-- Jamie
Stefan Weil - Aug. 27, 2009, 4:25 p.m.
Reimar Döffinger schrieb:
> On Thu, Aug 27, 2009 at 06:01:24PM +0530, Amit Shah wrote:
>   
>> eepro100.c shouldn't have the need to do this in its local header file.
>>
>> And I recently started getting this:
>>
>> $ make -j3
>> ...
>>   CC    x86_64-softmmu/eepro100.o
>> /home/amit/src/qemu/hw/eepro100.c:112: error: two or more data types
>> in declaration specifiers
>> /home/amit/src/qemu/hw/eepro100.c:112: warning: useless type name in
>> empty declaration
>> make[1]: *** [eepro100.o] Error 1
>>
>> so just remove the typedef and include <stdbool.h> instead.
>>
>> Signed-off-by: Amit Shah <amit.shah@redhat.com>
>> ---
>>  hw/eepro100.c |    3 +--
>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/eepro100.c b/hw/eepro100.c
>> index 8988b3f..0634f8c 100644
>> --- a/hw/eepro100.c
>> +++ b/hw/eepro100.c
>> @@ -38,6 +38,7 @@
>>  #endif
>>  
>>  #include <stddef.h>             /* offsetof */
>> +#include <stdbool.h>
>>  #include "hw.h"
>>  #include "pci.h"
>>  #include "net.h"
>> @@ -109,8 +110,6 @@
>>  #define INT_MASK        0x0100
>>  #define DRVR_INT        0x0200  /* Driver generated interrupt. */
>>  
>> -typedef unsigned char bool;
>> -
>>     
> I doubt it matters much, but
> 1) stdbool bool is probably 4 bytes, not just 1 like char
>   

This is no problem in eepro100.c

> 2) all assignments to bool variable are converted to 0/1 which could
> make a speed difference (not here since the code actually does that
> explicitly).
>   

Only C++ compilers do convert bool assignments to false / true.

> 3) is stdbool.h available everywhere where qemu is supposed to compile?
>   

Yes. nbd.h uses it for more than a year now.

> I suggest to just get rid of bool in this file, it is only used in 5
> places, i.e. change
>   
>>        bool bit_el = ((command & 0x8000) != 0);
>>     
> to
>   
>>        int bit_el = command & 0x8000;
>>     
>
>   

This would be possible, but I like my code as it is (as long as it is
not wrong) :-)
and prefer to keep bool. Using stdbool.h as suggested by the patch is ok
(only a small hint: I prefer to sort standard includes alphabetically if
there
are no special reasons against this sorting. Sorting additional lines
instead
of adding them to the end also reduces merge conflicts).

Regards

Stefan
Reimar Döffinger - Aug. 27, 2009, 4:43 p.m.
On Thu, Aug 27, 2009 at 06:25:44PM +0200, Stefan Weil wrote:
> Reimar Döffinger schrieb:
> > 2) all assignments to bool variable are converted to 0/1 which could
> > make a speed difference (not here since the code actually does that
> > explicitly).
> >   
> 
> Only C++ compilers do convert bool assignments to false / true.

Better learn the language you use.
From the C99 spec:
  6.3.1.2 Boolean type
  1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal
    to 0; otherwise, the result is 1.

stdbool.h defines bool to _Bool. As such the typedef is a horrible idea
since it behaves wrong.

Patch

diff --git a/hw/eepro100.c b/hw/eepro100.c
index 8988b3f..0634f8c 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -38,6 +38,7 @@ 
 #endif
 
 #include <stddef.h>             /* offsetof */
+#include <stdbool.h>
 #include "hw.h"
 #include "pci.h"
 #include "net.h"
@@ -109,8 +110,6 @@ 
 #define INT_MASK        0x0100
 #define DRVR_INT        0x0200  /* Driver generated interrupt. */
 
-typedef unsigned char bool;
-
 /* Offsets to the various registers.
    All accesses need not be longword aligned. */
 enum speedo_offsets {