== Why is this an issue?

The real need for bit fields is narrow and highly specialized. Previously, they were used to save memory, but that's less a concern in modern systems than are the extra instructions required to interact with them. Today, they may be needed in direct hardware interaction, but since their behavior is platform-dependent, getting them right can be tricky, and since their use is increasingly rare these days, they're likely to confuse maintainers. For these reasons, it's simpler and more performant to use another field type instead of bit fields.


=== Noncompliant code example

[source,cpp]
----
unsigned int b1 : 3;  // Noncompliant
unsigned char b2 : 3;  // Noncompliant
----


=== Compliant solution

[source,cpp]
----
unsigned int b1;
unsigned char b2;
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Use an "int" instead of a bit field.


'''
== Comments And Links
(visible only on this page)

=== on 22 May 2015, 08:06:24 Evgeny Mandrikov wrote:
\[~ann.campbell.2] any particular reason for "critical" and "active by default"?


I have feeling that at least should not be activated by default, because likely will generate a lot of issues, which might be not easily fixable, especially for projects with long evolution history, which is quite common in C world.

=== on 22 May 2015, 12:02:50 Ann Campbell wrote:
Active and Critical because there seems to be little justification for bit fields. But I've marked it inactive.

endif::env-github,rspecator-view[]
