Page History

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|AA. C References#ISO/IEC 9899-1999]\].

The C99 standard integer conversion 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 conversions result in the same numerical value, which causes least surprise values, and that these values minimize surprises in the rest of the computation. Pre-standard Prestandard C usually preferred to preserve signedness of the type.

...

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 eight8-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 conversion from int back to signed char does not result in lost data.

...

• No two different signed integer types have the same rank, even if they have the same representation.
• The rank of a signed integer type is greater than the rank of any signed integer type with less precision.
• The rank of long long int is greater than the rank of long int, which is greater than the rank of int, which is greater than the rank of short int, which is greater than the rank of signed char.
• The rank of any unsigned integer type is equal to the rank of the corresponding signed integer type, if any.
• The rank of any standard integer type is greater than the rank of any extended integer type with the same width.
• The rank of char is equal to the rank of signed char and unsigned char.
• The rank of any extended signed integer type relative to another extended signed integer type with the same precision is implementation - defined but still subject to the other rules for determining the integer conversion rank.
• For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than T3, then T1 has greater rank than T3.

...

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 \—1 cannot be represented as an unsigned int value, and unsigned int is treated modularly, the -1 \—1 is converted to UINT_MAX. Consequently, the program prints 0, because UINT_MAX is not less than 1.

...

This program prints 1 as expected. Note that (int)yui is only 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:

...

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 converting from negative to unsigned.

...

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

...

\[[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"

...