Integer constants that appear in the controlling expressions of #if and #elif preprocessing directives;
Any other integer constants that exist after preprocessing.

Note: during preprocessing, the type of an integer constant is determined in the same manner as after preprocessing except that:

All signed integer types behave as if they were long (C90) or intmax_t (C99);
All unsigned integer types behave as if they were unsigned long (C90) or uintmax_t (C99).

Rationale

The type of an integer constant is a potential source of confusion, because it is dependent on a complex combination of factors including:

The magnitude of the constant;
The implemented sizes of the integer types;
The presence of any suffixes;
The number base in which the value is expressed (i.e. decimal, octal or hexadecimal).

For example, the integer constant 40000 is of type signed int in a 32-bit environment but of type signed long in a 16-bit environment. The value 0x8000 is of type unsigned int in a 16-bit environment, but of type signed int in a 32-bit environment.

Note:

Any value with a “U” suffix is of unsigned type;
An unsuffixed decimal value less than 2³¹ is of signed type.

But:

An unsuffixed hexadecimal value greater than or equal to 215 may be of signed or unsigned type;
For C90, an unsuffi xed decimal value greater than or equal to 231 may be of signed or unsigned type.

Signedness of constants should be explicit. If a constant is of an unsigned type, applying a “U” suffix makes it clear that the programmer understands that the constant is unsigned.

Note: this rule does not depend on the context in which a constant is used; promotion and other conversions that may be applied to the constant are not relevant in determining compliance with this rule.

Example

The following example assumes a machine with a 16-bit int type and a 32-bit long type. It shows the type of each integer constant determined in accordance with The Standard. The integer constant 0x8000 is non-compliant because it has an unsigned type but does not have a “U” suffix.

Constant	Type	Compliance
32767	signed int	Compliant
0x7fff	signed int	Compliant
32768	signed long	Compliant
32768u	unsigned int	Compliant
0x8000	unsigned int	Non-compliant
0x8000	u unsigned int	Compliant

MISRA-C 2004 Rule 10.6 (required): A "U" suffix shall be applied to all constants of unsigned type.

Unsigned integer literal without 'U' suffix.

The type of an integer constant is a potential source of confusion, because it is dependent on a complex combination of factors including:

The magnitude of the constant
The implemented sizes of the integer types
The presence of any suffixes
The number base in which the value is expressed (i.e. decimal, octal or hexadecimal).

For example, the integer constant "40000" is of type int in a 32-bit environment but of type long in a 16-bit environment. The value 0x8000 is of type unsigned int in a 16-bit environment, but of type (signed) int in a 32-bit environment. Note the following:

Any value with a "U" suffix is of unsigned type
An unsuffixed decimal value less than 231 is of signed type

But:

An unsuffixed hexadecimal value greater than or equal to 215 may be of signed or unsigned type
An unsuffixed decimal value greater than or equal to 231 may be of signed or unsigned type

Signedness of constants should be explicit. Consistent signedness is an important principle in constructing well formed expressions. If a constant is of an unsigned type, it is helpful to avoid ambiguity by applying a "U" suffix. When applied to larger values, the suffix may be redundant (in the sense that it does not influence the type of the constant); however its presence is a valuable contribution towards clarity.

MISRA-C++ 2008 Rule 2-13-3 (required): A "U" suffix shall be applied to all octal or hexadecimal integer literals of unsigned type.

Rationale

The type of an integer is dependent on a complex combination of factors including:

The magnitude of the constant;
The implemented sizes of the integer types;
The presence of any suffixes;
The number base in which the value is expressed (i.e. decimal, octal or hexadecimal).

For example, the value 0x8000 is of type unsigned int in a 16-bit environment, but of type (signed) int in a 32-bit environment. If an overload set includes candidates for an unsigned int and an int, then the overload that would be matched by 0x8000 is therefore dependent on the implemented integer size. Adding a " u" suffix to the value specifies that it is unsigned.

Note that the usage context may also require the use of suffixes, as shown in Section 6.5.0.

Example

template <typename T>
void f ( T );

template <>
void f < uint16_t > ( uint16_t );

template <>
void f < int16_t > ( int16_t );

void b ( )
{
   uint16_t u16a = 0U;   // Compliant
   f ( 0x8000 );         // Non-compliant on a 16-bit platform.
   u16a = u16a + 0x8000; // Non-compliant as context is unsigned.
}