rspec/rules/S5494/cfamily/rule.adoc

== Why is this an issue?

Bit fields allow the developers to declare a class member with a specific size. 

However, the size of a bit field is also constrained by its type: even if the specified size is greater than the size of the type, the value of the bit field will not exceed the maximum value of this type. The extra bits will just create unused padding.

The incompatibility of the size of the type with the specified size can have two causes: either the specified size is a typo error (that is the most probable cause) or the developer did not realize the size of the type he chose was too small. 


=== Noncompliant code example

[source,cpp]
----
class A {
  unsigned int b : 55; // Noncompliant, specified size is greater than the size of unsigned int
};
----


=== Compliant solution

[source,cpp]
----
class A {
  unsigned int b : 32;
};
----
Or

[source,cpp]
----
class A {
  unsigned long long int b : 55;
};
----


ifdef::env-github,rspecator-view[]
'''
== Comments And Links
(visible only on this page)

=== on 6 Nov 2019, 11:25:48 Nicolas Harraudeau wrote:
\[~loic.joly] Shouldn't this rule be a bug? It seems to me that a scientist setting the wrong bit field size would get unexpected truncations.

=== on 16 Dec 2019, 11:18:31 Loïc Joly wrote:
Scientists should not work with bit fields :)

Anyways, this looks like a bug, but we may have issues with detection of the runtime environment, maybe leading to false positives...

Got to think more about this...

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