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

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).

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

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

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.