Main Content

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

expand all in page

Description

Rule Definition

The names of the standard signed integer types and standard unsigned integer types should not be used.

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 unsinged. 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);
Generally, strong typing using classes or enumerations is more robust than creating user-defined aliases for specific-width integers.

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 argc parameter to main()

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 unsinged. As exceptions, violations are not reported when standard signed or unsigned integer type names are used in:

  • The main() function definition

  • Postfix operator parameters

  • typedef or using statements

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

expand all

This example uses the standard signed and unsigned integer type names that do not specify the size of the object. The rule checker reports violations. As exceptions, violations are not reported when standard integer type names are used in the main() function definition, typedef statements, using statements, and postfix operator parameters.

#include <cstdint>
#include <cstddef>

int an_int1 = 0;            // Noncompliant
const int a_const_int1 = 0; // Noncompliant
int32_t an_int2 = 0;        // Compliant
int *ip = new int;          // Noncompliant
int32_t *ip_32 = new int32_t; // Compliant

bool flag = static_cast<bool>(0U); // Compliant
using myint_t = int;        // Compliant - Compliant by exception
typedef long mylong;        // Compliant - Compliant by exception

class MyClass
{
public:
	MyClass operator++ (int x);     // Compliant - Compliant by exception
};
int func(       // Noncompliant
                int,          // Noncompliant
                unsigned int  // Noncompliant
) {}

int main(int argc, char *argv[]) {} // Compliant - Compliant by exception

Check Information

Group: Basic Concepts
Category: Advisory

Version History

Introduced in R2024b

See Also

Topics