Our website uses cookies to enhance your browsing experience.
Accept
to the top
>
>
>
V2591. MISRA. Bit fields should only...
menu mobile close menu
Additional information
toggle menu Contents

V2591. MISRA. Bit fields should only be declared with explicitly signed or unsigned integer type.

Jul 30 2026

This diagnostic rule is based on the software development guidelines developed by MISRA (Motor Industry Software Reliability Association).

To declare bit-fields, explicitly specify a valid underlying type. Depending on the programming language and the standard version being used, the types may differ.

  • C90: signed int or unsigned int.
  • C99: signed int, unsigned int, _Bool, or another implementation-defined integral type, with explicitly specified signed or unsigned modifier.
  • C++: a bit-field must have a signed or unsigned integral underlying type, provided that all its values can be propagated within the bit-field width. An enumeration with the fixed underlying type is also allowed, as long as the same condition is satisfied.

It is also allowed to use an alias (typedef) for a valid type.

A bit field of int type can be signed or unsigned depending on the compiler. If you use unsigned int to represent a bit field, all the bits allocated for the field will be significant. Such a bit field of n bits has a range of values [0, 2 ^ n - 1].

If you use signed int to represent the bit field, 1 bit will be allocated for the sign. To write a significant part of a bit field value a developer will use 1 bit less than allocated. Such a bit field of n bits has a range of values [-2 ^ (n - 1), 2 ^ (n - 1) - 1].

So, depending on the compiler, bit fields of int type may have different ranges of values. To avoid potential errors, explicitly specify the modifier (signed or unsigned).

An example of a bit field misuse:

struct S
{
  int b : 3; // <=
};

void foo()
{
  S s;
  s.b = 5;
  if (s.b != 5)
  {
    Boom();
  }
}

In this example, the compiler may choose an unsigned type for b bit field representation. This way all 3 bits in which 5 is written will be significant. In fact, a modulo 8 residue is written. The code will work as expected—5 will be written to the bit field.

If the compiler chooses a signed type to represent the b bit field, the latter splits into 1-bit sign and 2 bits of a significant part. When writing 5 in b, only 2 low bits will be written in significant part. 1 will be written in the bit field instead of 5. The check will pass, the Boom function will be called.

To fix it, explicitly specify the modifier (signed/unsigned):

struct S
{
  unsigned int b : 3;
};

void foo()
{
  S s;
  s.b = 5;
  if (s.b != 5)
  {
    Boom();
  }
}

Explicitly specify which types are allowed to declare bit fields by your compiler that supports C99 standard. To do this, add the following comment to the source code or the .pvsconfig file.

//V_2591_ALLOWED_C99_TYPES:short,long long

After the colon, write allowed types in a comma-separated list and do not specify signed/unsigned:

  • char
  • short
  • long
  • long long

This diagnostic is classified as:

  • MISRA-C-2012-Rule-6.1
  • MISRA-C-2023-Rule-6.1

What a quick draw in the Wild West of Coding —
you caught the bug in sec!
But we catch them in milliseconds. How about a duel?

Try free