Why is this an issue?
This is a draft version of a MISRA C++ 202x rule proposed for public review.
MISRA Rule 5.13.4
Analysis Type: Decidable,Single Translation Unit
This rule applies to any integer-literal that exists after preprocessing. It does not apply to user-defined-integer-literals.
An unsigned integer-suffix is required when the type of the integer literal, as specified by the C++ Standard in [lex.icon], is
Note: this rule does not depend on the context in which a literal is used; promotion and other conversions that may be applied to
the value are not relevant in determining compliance with this rule.
The type of an integer literal is a potential source of confusion, because it is dependent on a complex combination of factors
- The magnitude of the constant;
- The implemented sizes of the integer types;
- The presence of any suffixes;
- The number base that is used.
For example, the decimal integer literal
32768 always has signed type. However, the integer literal
0x8000 is of type
unsigned int in a 16-bit environment, but of type
signed int in a 32-bit environment. Adding
u suffix to the integer literal makes the signedness of the value explicit on a 16-bit platform.
Note: compliance checks against this rule will only be valid if an analysis tool has been configured with the same integer sizes
as the compiler that is being used within the project.
The following examples assume that
int is 16 bits:
auto x = 32768; // Compliant - signed type
auto y = 0x8000; // Non-compliant - unsigned type
uint16_t z = 123; // Compliant - 'u' is not required as '123' is signed
void f( uint16_t ); // #1
void f( int16_t ); // #2
f( 0x8000 ); // Non-compliant - calls #1 as 0x8000 is unsigned
f( 0x8000u ); // Compliant - calls #1
f( 0x7FFF ); // Compliant - calls #2 as 0x7FFF is signed
f( 0x7FFFu ); // Compliant - calls #1
Copyright The MISRA Consortium Limited © 2023
S854 targets the same defect as this rule but for a non-mission-critical context.