MISRA C++:2023 Rule 12.2.2

A bit-field shall have an appropriate type

Since R2024b

Description

Rule Definition

A bit-field shall have an appropriate type.

Rationale

Certain types are not appropriate for bit-fields because their signedness is implementation-defined. For example, if you use the types char, wchar_t, or an unscoped enum without specifying the underlying type, these issues can occur:

The bit-field is too small to store its assigned value because its signedness limits the range of values it can assume.
Sign extension occurs when you assign a value to the bit-field, propagating the sign bit to higher-order bits and changing the interpretation of the value stored in the bit-field.

The types char16_t and char32_t are also not appropriate for bit-fields because they are intended to only represent Unicode characters in UTF-16 and UTF-32 encodings, respectively. Using types designed for Unicode representation with bit-fields which are typically used for packing data tightly can reduce code readability and make the code harder to maintain.

Instead, use one of these types with bit-fields:

Signed or unsigned integer types.
A Boolean.
An enumerated type with an underlying type of signed or unsigned integer type. Bit-fields declared with these enumerated types must have bit widths large enough to accommodate all the values of the enumerated type.

Polyspace Implementation

The coding rule checker reports a violation when the underlying type of a bit-field is one of these:

A char or wchar_t type.
An unscoped enumeration with no specified underlying type.
An unscoped enumeration where width of the bit-field does not accommodate all the enumerator values.

Troubleshooting

If you expect a rule violation but Polyspace^® does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

expand all

Bit-Fields with Inappropriate Types

typedef char customType;

struct myTypes
{
    signed short var1 : 5;
    unsigned short var2 : 6;

    long var3 : 7;
    unsigned long var4 : 8;
    customType var5 : 4; // Noncompliant
    wchar_t var6 : 2; // Noncompliant
};

enum unscopedEnum
{
    val0, 
    val1 = 1014
};

struct myStruct
{
    unscopedEnum field1 : 2; // Noncompliant 
    unscopedEnum field2 : 3; // Noncompliant 
};

In this example, Polyspace reports a violation of the coding rule for these member variables of struct myTypes:

var5 — The type customType corresponds to char, which has implementation-defined signedness. If char is signed, var5 is not large enough to hold all possible values assigned to it.
var6 — The type of this member variable is wchar_t, which is not an appropriate type for a bit-field for the same reason the type char is not appropriate for the bit-field var5.

Similarly, both member variables of structure myStruct with type unscopedEnum are noncompliant. For each member variable, Polyspace reports two violations:

The underlying type of the bit-field is an unscoped enum with an unspecified type. If the underlying type of the enumerated type is signed, then the member variables field1 and field2 are not big enough to store all possible values of the enumeration.
The bit width of the bit-field is not large enough to represent all the enumerator values of enumeration unscopedEnum.

Check Information

Group: Classes

Category: Required

Version History

Introduced in R2024b