I used bit fielded named flags for the same reason as Nigel – when it makes sense to do so and it saves me space. If I want a list of bits for checking, I use an INT16 size value (with comments that its bit fielded) and use masks and loops.

Its horses for courses.

If you have ever done any ADA you will find bit fields dont exist for all the reasons of evilness cited, and this turns out to be a major pain in the neck. I spent a few happy hours writing my own Ada83 bit manipulation package because using things like arrays of booleans turns out to be hideous, as well as slow.

Moral of the story: There is no one right solution which will solve every problem known to man.

Usualyl when using fields like this for flags the code will be larger than just accessing a plain boolean in a byte. However, if you have the common problem on a micro of plenty of flash and not enough RAM then its a case of beggars not being choosers. A little extra flash to fiddle the bits is nothing if if buys you back the RAM you need.

Using things like a 3-bit named quantity TENDS in the long run to make your code far more readable and less error prone than explicitly writing something like (buffer[x] & 0xC8)>>3.

When you find yourself doing the above more than about twice, there needs to be a better way. Sometimes an objecty-sort of approach (getter / setter) is the way to go but this can be horribly inefficient for run time speed if there is a function call overhead associated. A bit-fielded structure definition solve the problem. Just so long as you know what the compiler will do, document that in comments, and use the option in your makefile to force the compiler to always allocated fielded structures the way you wanted.

Hatton, Les, Safer C: developing software for high-integrity and safety-critical systems. ISBN 0-07-707640-0.

—

As for readability of bit fields:
The whole point of using flags on bit level, rather than “byte flags” (typedef BOOL uint8_t), is that you want to save memory space. Since we have this requirement to save memory space for the application, we can safely assume that there is a lot of flags present (8 or more), or we wouldn’t use bit fields in the first place.

Then how do you check all flags in a loop? A very common task in my experience. With bitwise operators this is very straight-forward:

/* “flags” is a pure integer */
for(mask=0×01; mask!=0×00; mask< 0)
{
do_something();
}
}

This loop could easily be modified by some memory guru to optimize for cache memory access etc. It has the potential to become extremely efficient without sacrificing readability.

With C bit fields, you -cannot- use a loop like that, since you don’t know where the bits are allocated. You -must- do like this:

/* “flags” is a C bit field */
BOOL do_it = FALSE;

switch(i)
{
case SOME_CONSTANT:
if(flags.foo > 0)
{
do_it = TRUE;
}
break;

case SOME_OTHER_CONSTANT:
if(flags.bar > 0)
{
do_it = TRUE;
}
break;

…
/* 30 more case statements here to check a uint32 */

default:
}

if(do_it)
{
do_something();
}

And now I’d like to hear exactly how a vast amount of case statements is more readable than a 3 line loop! Not to mention that code size and execution speed is far worse with the switch statement.

—

Still, the real argument here is that bit fields come with countless amounts of pit falls. Introducing them to your program is to introduce a great bug potential, while at the same time throwing all portability away.

Anyway, if this is how one uses flags variables, then it doesn’t matter where the compiler places them in memory. What matters to me is that I can now write very clear code. For example:
if (flags.foo)
{
flags.bar = 0;
}

Doing the same with bit masks and macros, the above code tends to look something like this:
if (flags & BIT(3))
{
flags &= ~BIT(6);
}
Clearly one can define some intermediate macros. For example:
#define FOO BIT(3)
#define BAR BIT(6)
if (flags & FOO)
{
flags &= ~BAR;
}
However IMHO it still isn’t as clear as the bit field representation. I’d also note that for code like this to be reliable, one has to be very careful about the definition of the BIT() macro. There’s also the issue of the underlying type of the flags variable. For example:
uint8_t flags;
…
flags |= BIT(9);
Good compilers will warn you that this operation is useless. Not so good compilers will happily let you do this. Of course Lint will catch it

How can something be readable when you have no idea where the bits end up in the memory cells? Assuming that the reader doesn’t have in-depth knowledge of the specific compiler’s bit field handling.

Flags.bar = 1U;

From this I can tell that “bar” is given the value 1. I have no idea whatsoever where “bar” is allocated, or how much space that is allocated by the structure it resides in. That might be sufficient for the average PC programmer, but not for them picky embedded folks who want to know exactly where all ones and zeroes end up.

But the real problems begin when I do like this:

uint8_t x = Flags.bar;

There is just no way I can know what value the uint8 has after that line, unless I read the compiler front-end documents. And what about this:

uint8_t value;
uint8_t mask;
…
if((value & Flags.bar) == mask)

Even if “Flags” was allocated as an ISO C bit field, I still doubt very few C programmers can tell you straight away what this code actually results in, because of the implicit integer promotion madness that the compiler will conjure. I cannot, not without scratching my head for at least half an hour and reading up on both the C standard and the compiler docs.

If I were using the bitwise operators instead, nothing would be ambiguous, and I wouldn’t need to use the struct notation either. Then I could read/write the same code in one minute and the code would be completely deterministic under any C compiler for any system.

The most blatant one is indeed that the code will not compile under a standard C compiler. As Nigel points out, bit fields can only be of type int, signed int or unsigned int. Sure, there are many many non-standard compilers out there. Just because they allow some inane non-standard syntax doesn’t mean it should be used. Good code == portable code, especially in embedded systems.

The next mistake is to use structs/unions for bit mapping. According to the standard, the compiler may add any number of padding bytes into a struct/union, and bit fields are no exception to this rule. This is the main reason MISRA bans unions. So all we know about that union is that its size >= 1 byte. If you use an array of such struct/unions, you are asking for trouble.

The royal mistake is to use bit fields in the first place. The following is not specified by the standard:

- whether bit field int is treated as signed or unsigned int
- the bit order (lsb is where?)
- whether the bit field can reach past the memory alignment of the CPU or not
- the alignment of non-bit field members of the struct
- the memory alignment of bit fields (to the left or to the right?)
- the endianess of bit fields larger than one byte
- whether plain int values assigned to them are interpreted as signed or unsigned
- how bit fields are promoted implicitly by the integer promotions
- whether signed bit fields are one’s compliment or two’s compliment
- padding bytes
- padding bits
- values of padding bits.
- and so on.

The only thing you know when declaring a bit field is that you have an unportable chunk of random data of a random size, that the program may use in random ways.

Flags.bar = 1U; /* Set the bar flag */

If we ignore the fact that 8-bit bit fields aren’t even valid C, here is just a few examples of what result this line of code will yield:

0×02
0×40
0×0002
0×4000
0×0200
0×0040
0×00000002
0×40000000
0×02000000
0×40000000
0x02ABCDEF
0x40ABCDEF

Most important of all, bit fields will never be more efficient than plain bit-wise operators, but can be less efficient in many ways. Though of course, you have to write a PhD thesis about bit fields before you can actually tell what code they will yield, since they are so incredibly poorly defined.

Don’t use bit fields ever.

Certainly if you are using flag registers like this to get smaller or faster code (or use less RAM space), then it’s important to test it out and check the generated assembly from your compiler. If you are unsure about the bit ordering, then again this is something to check.

In the end, it’s a style choice. The most important factor is that it produces correct code, and that it is easy to read and understand. If it produces good code from your compiler, then that’s useful too!