Are there reasons to avoid bit-field structure mem

Question

I long knew there are bit-fields in C and occasionally I use them for defining densely packed structs:

typedef struct Message_s {
     unsigned int flag : 1;
     unsigned int channel : 4;
     unsigned int signal : 11;
} Message;

When I read open source code, I instead often find bit-masks and bit-shifting operations to store and retrieve such information in hand-rolled bit-fields. This is so common that I do not think the authors were not aware of the bit-field syntax, so I wonder if there are reasons to roll bit-fields via bit-masks and shifting operations your own instead of relying on the compiler to generate code for getting and setting such bit-fields.

Answer 1

Are there reasons to avoid bitfield-structs?

bitfield-structs come with some limitations:

1. Bit fields result in non-portable code. Also, the bit field length has a high dependency on word size.
2. Reading (using scanf()) and using pointers on bit fields is not possible due to non-addressability.
3. Bit fields are used to pack more variables into a smaller data space, but cause the compiler to generate additional code to manipulate these variables. This results in an increase in both space as well as time complexities.
4. The sizeof() operator cannot be applied to the bit fields, since sizeof() yields the result in bytes and not in bits.

Source

So whether you should use them or not depends. Read more in Why bit endianness is an issue in bitfields?

---

PS: When to use bit-fields in C?

Answer 2

There is no reason for it. Bitfields are useful and convenient. They are in the common use in the embedded projects. Some architectures (like ARM) have even special instructions to manipulate bitfields.

Just compare the code (and write the rest of the function foo1) https://godbolt.org/g/72b3vY

Answer 3

Why other programmers use hand-coded bit manipulations instead of bitfields to pack multiple fields into a single word?

This answer is opinion based as the question is quite open:

• Many programmers are unaware of the availability of bitfields or unsure about their portability and precise semantics. Some even distrust the compiler's ability to produce correct code. They prefer to write explicit code that they understand.

  As commented by Cornstalks, this attitude is rooted in real life experience as explained in this article.

• Bitfield's actual memory layout is implementation defined: if the memory layout must follow a precise specification, bitfields should not be used and hand-coded bit manipulations may be required.
• The handing of signed values in signed typed bitfields is implementation defined. If signed values are packed into a range of bits, it may be more reliable to hand-code the access functions.

Answer 4

In many cases, it is useful to be able to address individual groups of bits within a word, or to operate on a word as a unit. The Standard presently does not provide any practical and portable way to achieve such functionality. If code is written to use bitfields and it later becomes necessary to access multiple groups as a word, there would be no nice way to accommodate that without reworking all the code using the bit fields or disabling type-based aliasing optimizations, using type punning, and hoping everything gets laid out as expected.

Using shifts and masks may be inelegant, but until C provides a means of treating an explicitly-designated sequence of bits within one lvalue as another lvalue, it is often the best way to ensure that code will be adaptable to meet needs.