MISRA C++:2023 Rule 6.9.2
The names of the standard signed integer types and standard unsigned integer types should not be used
Since R2024b
Description
Rule Definition
The names of the standard signed integer types and standard unsigned integer types should not be used. 1
Rationale
The storage required for standard signed integer types and standard unsigned standard types is implementation-dependent. The standard signed and unsigned integer types include names of integral types constructed using the keywords char, short, int, long, singed, and unsigned. Using these types can result in ambiguity regarding the amount of storage required. This rule
does not apply to the use of plain char.
Using types with specific widths unambiguously determines the required storage. Use the standard library header cstdint, which typically provides a suitable set of specific-width integer types. Alternatively, you can define your own specific-width aliases. When defining your own type aliases, best practice is to validate the sizes of these aliased types by using static_assert:
using uint8_t = unsigned char; static_assert(sizeof(uint8_t) == 1);
Using specific-width integer types does not prevent integer promotion. For example, an integer of type int16_t is promoted if the aliased type of int16_t has a rank lower than int.
As exceptions, the standard signed or unsigned integer types do not violate this rule when used in alias statements such as typedef or using statements. The type name int is also allowed as:
The parameter to a postfix operator
The return type of
main()The
argcparameter tomain()
Polyspace Implementation
This rule checker reports a violation of this rule if the code uses standard signed or unsigned integer type names constructed using the keywords char, short, int, long, singed, and unsigned. As exceptions, violations are not reported when standard signed or unsigned integer type names are used in:
The
main()function definitionPostfix operator parameters
typedeforusingstatements
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
Check Information
| Group: Basic Concepts |
| Category: Advisory |
Version History
Introduced in R2024b
1 All MISRA coding rules and directives are © Copyright The MISRA Consortium Limited 2021.
The MISRA coding standards referenced in the Polyspace Bug Finder™ documentation are from the following MISRA standards:
MISRA C:2004
MISRA C:2012
MISRA C:2023
MISRA C++:2008
MISRA C++:2023
MISRA and MISRA C are registered trademarks of The MISRA Consortium Limited 2021.