Page History

...

The C99 standard rules define how C compilers handle conversions. These rules include integer promotions, integer conversion rank, and the usual arithmetic conversions. The intent of the rules is to ensure that the conversion results in the same numerical value, which causes least surprise in the rest of the computation. Pre-standard 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:

...

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 eight-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 truncation does not result in lost data.

Integer Conversion Rank

Every integer type has an integer conversion rank that determines how conversions are performed. The ranking is based on the concept that each integer type contains at least as many bits as the types ranked below it. The following rules for determining integer conversion rank are defined in C99:

...

The integer conversion rank is 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.

1. If both operands have the same type, no further conversion is needed.
2. 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.
3. 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.
4. 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.
5. 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:

...

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.

...

Noncompliant Code Example (Comparison)

Care must be taken when performing operations on mixed types. This non-compliant 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 non-compliant noncompliant code example can be modified to produce the intuitive result by forcing the comparison to be performed using signed int values.

...

int si = /* some signed value */;
unsigned ui = /* some unsigned value */;
printf("%d\n", (si < 0 || (unsigned)si < ui));

Automated Detection

Compass/ROSE does not currently detect violations of this rule, but it can by merely reporting comparisons between unsigned integer types and signed integer types.

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), or converting from unsigned to signed, or from negative to unsigned.

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, permitting the vulnerability to exist.

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Dowd 06|AA. C References#Dowd 06]\] Chapter 6, "C Language Issues" (Type Conversions 223-270)
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.3, "Conversions"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "FLC Numeric Conversion Errors"
\[[MISRA 04|AA. C References#MISRA 04]\] Rules 10.1, 10.3, 10.5, and 12.9
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 192|http://cwe.mitre.org/data/definitions/192.html], "Integer Coercion Error"; [CWE ID 197|http://cwe.mitre.org/data/definitions/197.html], "Numeric Truncation Error"
\[[Seacord 05a|AA. C References#Seacord 05]\] Chapter 5, "Integers"

...

INT01-C. Use rsize_t or size_t for all integer values representing the size of an object      04. Integers (INT)       INT03-AC. Use a secure integer library