[En-Nut-Discussion] Nut/OS finally moving to C99 types

Nathan Moore nategoose at gmail.com
Fri Apr 18 19:38:14 CEST 2008


>
> >  What is the size of a bool and the size of an element in an array of
> >  booleans?
>
> I couldn't find that on the TCs (which are free, the ISO/IEC 9899:1999
> document actually costs 360 dollars). But I don't think it's much
> different than using bitfields. I suppose sizeof a struct with 8 bools
> should be the same as the sizeof a char bitfield. sizeof(bool) should
> yield 1, and sizeof arrays should always return the number of elements
> AFAIK.
>

Compilers aren't generally able to compress bools into bitfields on their
own.
On AVR if it and wasn't really really smart you'd end up with some ratty
code
because standard bitfield implementation uses 1 << y a lot and AVR only has
<< 1, so this would mean looping or repeating the shifts.

If you want to create a structure with boolean members all packed up you'll
need to do:
struct A {
    bool  b0:1;
    bool  b1:1;
    bool  b2:1;
 /*...*/
};
Note that you can also use most any integer type where bool is, and that
compilers differ in the
bit and byte endianness in this case.  It's also tricky mixing it with other
non-packed types
or bigger ( z:2 ) types.  Another thing is that the compiler may have a
limit on the overall size
and that using it may result in reading in all the bytes even if you are
only interested in the bits
in one of them.

I've seen bools be sized the same as int or char.



>
> >  > It provides the compiler with optimization opportunities,
> >
> >  I'm not sure about this, but your answers to the questions above may
> >  convince me - in either way.
>
> This is most likely implementation defined. I don't know where to look
> for an ABI document, and I suppose there isn't one for embedded
> platforms anyway.


This wouldn't be in an ABI document, but it could help in dataflow analysis.
It could also work for places where someone may be looking for true to be 1
or -1 but ignoring other possible true values in a comparison since the
compiler
could either tell the programmer that they were doing a silly comparison or
be shady and just change it.
It'd also encourage cleaner programming that would avoid the above mentioned
comparison of Boolean function return values to values outside the range
{0,true}.

>
> >  > and I'm sure
> >  > the standards committee have seen other advantages other than just
> >  > syntax sugar, although that is reason enough in terms of readability.
> >
> >  In that specific sense, can you specify "readability"? In my view,
> >  readability implies consistency. If some functions return 0 and -1
> while
> >  others use true and false for the same purpose, readability suffers.
>
> Ok, you had me on the return types, but let's not be hasty in banning
> bools, we could use them in structs and arguments when they make
> sense.


I'd avoid most uses of bools in structures.  Use bit fields, and maybe you
can use some of the other bits
for some other boolean values.

Nathan



More information about the En-Nut-Discussion mailing list