Page History

Bitwise shifts include left-shift operations of the form shift-expression << additive-expression and right-shift operations of the form shift-expression >> additive-expression. The standard integer promotions are first performed on the operands, each of which has an integer type. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined (see undefined behavior 51.)

Do not shift a value an expression by a negative number of bits or by a number greater than or equal to the precision of the promoted left operand. The precision of an integer type is the number of bits it uses to represent values, excluding any sign and padding bits. For unsigned integer types the width and the precision are the same, while whereas for signed integer types the width is one greater than the precision.   We use This rule uses precision instead of width in this rule to prevent a bit change from escaping the value bits to enter the sign bit, which is a violation of INT32-C. Ensure that operations on signed integers do not result in overflow.In because, in almost every case, an attempt to shift by a negative number of bits or by more than greater than or equal to the precision of the operand indicates a bug (logic error). A logic error is different from overflow, in which there is simply a representational deficiency.  In general, shifts should only be performed on unsigned operands (see INT13-C. Use bitwise operators only on unsigned operands).

...

The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. The following diagram illustrates the left-shift operation:.

According to the C Standard, if E1 has an unsigned type, the value of the result is E1 * 2E2, reduced modulo 1 more than the maximum value representable in the result type. 

This noncompliant code example fails to ensure that the right operand is less than or equal to the precision of the promoted left operand:

...

This compliant solution eliminates the possibility of shifting by more bits than exist in the left hand greater than or equal to the number of bits that exist in the precision of the left operand:

#include <limits.h>
#include <stddef.h>
#include <inttypes.h>

extern size_t popcount(uintmax_t);
#define PRECISION(x) popcount(x)
 
void func(unsigned int ui_a, unsigned int ui_b) {
  unsigned int uresult = 0;
  if (ui_b >= PRECISION(UINT_MAX)) {
    /* Handle error condition */
  } else {
    uresult = ui_a << ui_b;
  }

  /* ... */
}

The PRECISION() macro  macro and popcount() function provide the correct precision for any integer type (see INT35-C. Use correct integer precisions).

...

The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has a signed type and nonnegative value, and E1 * 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

This noncompliant code example fails to ensure that left and right operands have nonnegative values and that the right operand is less than or equal to the precision of the promoted left operand. This example does check for signed integer overflow in compliance with INT32-C. Ensure that operations on signed integers do not result in overflow.

#include <limits.h>
#include <stddef.h>
#include <inttypes.h>
 

void func(signed long si_a, signed long si_b) {
  signed long result;
  if (si_a > (LONG_MAX >> si_b)) {
    /* Handle error */
  } else {
    result = si_a << si_b;
  }
  /* ... */
}

...

In addition to the check for overflow, this compliant solution ensures that both the left and right operands have nonnegative values and that the right operand is less than or equal to the precision of the promoted left operand:

...

When working with signed operands, making assumptions about whether a right shift is implemented as an arithmetic (signed) shift or a logical (unsigned) shift can also lead to vulnerabilities. See (see INT13-C. Use bitwise operators only on unsigned operands).

Compliant Solution (Right Shift)

This compliant solution eliminates the possibility of shifting by more bits than exist in the left hand greater than or equal to the number of bits that exist in the precision of the left operand:

#include <limits.h>
#include <stddef.h>
#include <inttypes.h>

 externextern size_t popcount(uintmax_t);
#define PRECISION(x) popcount(x)
 
void func(unsigned int ui_a, unsigned int ui_b) {
  unsigned int uresult = 0;
  if (ui_b >= PRECISION(UINT_MAX)) {
    /* Handle error condition */
  } else {
    uresult = ui_a >> ui_b;
  }
  /* ... */
}

...

Implementation Details

GCC has no options to handle shifts by negative amounts or by amounts outside the width of the type predictably or to trap on them; they are always treated as undefined. Processors may reduce the shift amount modulo the width of the type. For example, 32-bit shifts are implemented using the following instructions on x86-32:

...

where %eax stores the least significant bits in the doubleword to be shifted, and %edx stores the most significant bits.

...

INT34-EX1: The signed integer value zero can be shifted by the width and not the precision.  Assuming a 32-bit int, for example, the following expression is allowed:

 0 << 31;

INT34-EX2: Any positive integer value can be right shifted by the width of the promoted left hand operand.  For example, positive >> 31 is valid for implementations where int has a width of 32 bits, even if positive is a smaller type, such as char. However, any portable shift expression that takes advantage of the full width of a signed integer is guaranteed to have a result of zero, so it is not useful to shift beyond the precision.

Risk Assessment

Although shifting a negative number of bits or more or shifting a number of bits than exist in the greater than or equal to the width of the promoted left operand is undefined behavior in C, the risk is generally low because processors frequently reduce the shift amount modulo the width of the type.

...

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

...

Bibliography

...

[C99 Rationale 2003]	Subclause 6.5.7, "Bitwise Shift Operators"
[Dowd 2006]	Chapter 6, "C Language Issues"
[Seacord 20132013b]	Chapter 5, "Integer Security"
[Viega 2005]	Section 5.2.7, "Integer Overflow"

...