This guideline has not been reviewed recently and may be outdated. Please review it and comment to reflect any newly available information.
Conversions can occur explicitly as the result of a cast or implicitly as required by an operation. While conversions are generally required for the correct execution of a program, they can also lead to lost or misinterpreted data. Conversion of an operand value to a compatible type causes no change to the value or the representation [ISO/IEC 9899:1999].
The ISO/IEC 14882-2003 standard rules define how C++ compilers handle conversions. These rules include integral promotions, integral conversions, and the usual arithmetic conversions. The intent of the rules is to ensure that the conversions result in the same numerical values, and that these values minimize surprises in the rest of the computation. Prestandard C usually preferred to preserve signedness of the type.
Integer Promotions
Integer types smaller than int are promoted when an operation is performed on them. If all values of the original type can be represented as an int
, the value of the smaller type is converted to an int
; otherwise, it is converted to an unsigned int
.
Integer promotions are applied as part of the usual arithmetic conversions to certain argument expressions; operands of the unary +
, -
, and ~
operators, and operands of the shift operators. The following code fragment shows the application of integer promotions:
Integer promotions require the promotion of each variable (c1
and c2
) to int
size. The two int
values are added and the sum truncated to fit into the char
type.
Integer promotions are performed to avoid arithmetic errors resulting from the overflow of intermediate values. For example:
In this example, the value of c1
is multiplied by c2
. The product of these values is then divided by the value of c3
(according to operator precedence rules). Assuming that signed char
is represented as an 8-bit value, the product of c1
and c2
(300) cannot be represented. Because of integer promotions, however, c1
, c2
, and c3
are each converted to int
, and the overall expression is successfully evaluated. The resulting value is truncated and stored in cresult
. Because the final result (75) is in the range of the signed char
type, the conversion from int
back to signed char
does not result in lost data.
Integral promotions have a number of interesting consequences. For example, adding two small integer types always results in a value of type signed int
or unsigned int
, and the actual operation takes place in this type. Also, applying the bitwise negation operator ~ to an unsigned char
(on IA-32) results in a negative value of type signed int
because the value is zero-extended to 32 bits.
Integer Conversion Rank
Every integer type has an integer conversion rank that determines howconversions are performed. The ranking is based on the concept thateach integer type contains at least as many bits as the types rankedbelow it. The following rules for determining integer conversion rankare defined in C99:
- No two different signed integer types have the same rank, even ifthey have the same representation.
- The rank of a signed integer type is greater than the rank of anysigned integer type with less precision.
- The rank of
long long int
is greater than the rank oflongint
, which is greater than the rank ofint
, which is greaterthan the rank ofshort int
, which is greater than the rank of{{signed char}}. - The rank of any unsigned integer type is equal to the rank of thecorresponding signed integer type, if any.
- The rank of any standard integer type is greater than the rank ofany extended integer type with the same width.
- The rank of
char
is equal to the rank ofsigned char
and{{unsigned char}}. - The rank of any extended signed integer type relative to anotherextended signed integer type with the same precision isimplementation defined but still subject to the other rules for determining theinteger conversion rank.
- For all integer types T1, T2, and T3, if T1 has greater rank than T2and T2 has greater rank than T3, then T1 has greater rank than T3.
The integer conversion rank is used in the usual arithmeticconversions to determine what conversions need to take place tosupport an operation on mixed integer types.
Integral Conversions
ISO/IEC 14882-2003 section 4.7 says:
An rvalue of an integer type can be converted to an rvalue of another integer type. An rvalue of an enumeration
type can be converted to an rvalue of an integer type.If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source
integer (modulo 2^{n} where n is the number of bits used to represent the unsigned type). [Note: In a two's
complement representation, this conversion is conceptual and there is no change in the bit pattern (if there
is no truncation).]If the destination type is signed, the value is unchanged if it can be represented in the destination type (and
bit-field width); otherwise, the value is implementation-defined.
The integral conversions are used in the usual arithmetic conversions to determine what conversions need to take place to support an operation on mixed integer types.
Usual Arithmetic Conversions
The usual arithmetic conversions are rules that provide a mechanism to yield a common type when both operands of a binary operator are balanced to a common type or the second and third arguments of the conditional operator ( ? :
) are balanced to a common type. Balancing conversions involve two operands of different types, and one or both operands may be converted. Many operators that accept arithmetic operands perform conversions using the usual arithmetic conversions. After integer promotions are performed on both operands, the following rules are applied to the promoted operands.
- If both operands have the same type, no further conversion is needed.
- If both operands are of the same integer type (signed or unsigned), the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
- If the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type.
- If the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type is converted to the type of the operand with signed integer type.
- Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. Specific operations can add to or modify the semantics of the usual arithmetic operations.
Example
In the following example, assume the code is compiled using an implementation with 8-bit char
, 32-bit int
, and 64-bit long long
:
Both the signed char sc
and the unsigned char uc
are subject to integer promotions in this example. Because all values of the original types can be represented as int
, both values are automatically converted to int
as part of the integer promotions. Further conversions are possible, if the types of these variables are not equivalent as a result of the usual arithmetic conversions. The actual addition operation in this case takes place between the two 32-bit int
values. This operation is not influenced by the resulting value being stored in a signed long long
integer. The 32-bit value resulting from the addition is simply sign-extended to 64 bits after the addition operation has concluded.
Assuming that the precision of signed char
is 7 bits and the precision of unsigned char
is 8 bits, this operation is perfectly safe. However, if the compiler represents the signed char
and unsigned char
types using 31- and 32-bit precision (respectively), the variable uc
would need to be converted to unsigned int
instead of signed int
. As a result of the usual arithmetic conversions, the signed int
is converted to unsigned and the addition takes place between the two unsigned int
values. Also, because uc
is equal to UCHAR_MAX
, which is equal to UINT_MAX
, the addition results in an overflow in this example. The resulting value is then zero-extended to fit into the 64-bit storage allocated by sll
.
Note. The type long long int
is not defined in ISO/IEC 14882-2003 but it is defined in C99, and in the Working Draft of the next version of the language, and it is supported by many C++ compilers.
Noncompliant Code Example (Comparison)
Care must be taken when performing operations on mixed types. This noncompliant code example shows an idiosyncrasy of integer promotions.
In this example, the comparison operator operates on a signed int
and an unsigned int
. By the conversion rules, si
is converted to an unsigned int
. Because \—1 cannot be represented as an unsigned int
value, and unsigned int
is treated modularly, the \—1 is converted to UINT_MAX
. Consequently, the program prints 0, because UINT_MAX
is not less than 1.
Compliant Solution
The noncompliant code example can be modified to produce the intuitive result by forcing the comparison to be performed using signed int
values.
This program prints 1 as expected. Note that (int)ui
is correct in this case only because the value of ui
is known to be representable as an int
. If this were not known, the compliant solution would need to be written as:
Risk Assessment
Misunderstanding integer conversion rules can lead to errors, which in turn can lead to exploitable vulnerabilities. The major risks occur when narrowing the type (which requires a specific cast or assignment), converting from unsigned to signed, or converting from negative to unsigned.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
INT02-CPP | medium | probable | medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
CodeSonar | 4.4 | LANG.CAST.VALUE | Cast alters value Coercion alters value Truncation of allocation size Truncation of size |
1.2 | CP1.INT02 | Fully implemented | |
Klocwork | 2017 | MISRA.CAST.INT | |
LDRA tool suite | 9.5.8
| 52 S, 93 S, 96 S, 101 S, 107 S, 332 S, 334 S, 433 S, 434 S, 446 S, 452 S, 457 S, 458 S | Fully implemented |
Parasoft C/C++test | 9.5 | MISRA-043{b} | |
PRQA QA-C++ | 3.2 | 3000,3001,3002,3003,3005,3006,3007,3010,3011,3012,3015,3016 |
Related Vulnerabilities
This vulnerability in Adobe Flash arises because Flash passes a signed integer to calloc()
. An attacker has control over this integer and can send negative numbers. Because calloc()
takes size_t
, which is unsigned, the negative number is converted to a very large number, which is generally too big to allocate, and as a result calloc()
returns NULL causing the vulnerability to exist.
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
This rule appears in the C Secure Coding Standard as INT02-C. Understand integer conversion rules.
Bibliography
[Dowd 06] Chapter 6, "C Language Issues" (Type Conversions 223—270)
[ISO/IEC 9899:1999] Section 6.3, "Conversions"
[ISO/IEC PDTR 24772] "FLC Numeric Conversion Errors"
[MISRA 04] Rules 10.1, 10.3, 10.5, and 12.9
[MITRE 07] CWE ID 192, "Integer Coercion Error"; CWE ID 197, "Numeric Truncation Error"
[Seacord 05a] Chapter 5, "Integers"