Type conversions 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.
The C99 standard rules define how C compilers handle conversions. These rules include integer promotions, integer conversion rank, and the usual arithmetic conversions.
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 illustrates the use of integer promotions:
char c1, c2; c1 = c1 + c2; |
Integer promotions require the promotion of each variable (c1
and c2
) to int
size. The two ints
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:
char cresult, c1, c2, c3; c1 = 100; c2 = 90; c3 = --120; cresult = c1 + c2 + c3; |
In this example, the value of c1
is added to the value of c2
. The sum of these values is then added to the value of c3
(according to operator precedence rules). The addition of c1
and c2
would result in an overflow of the signed char
type because the result of the operation exceeds the maximum size of signed char
. Because of integer promotions, however, c1
, c2
, and c3
are each converted to integers and the overall expression is successfully evaluated. The resulting value is then truncated and stored in cresult
. Because the result is in the range of the signed char
type, the truncation does not result in lost data.
Every integer type has an integer conversion rank that determines how conversions are performed. 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.
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.
In the following example, assume the following code is compiled and executed on IA-32:
signed char sc = SCHAR_MAX; unsigned char uc = UCHAR_MAX; signed long long sll = sc + uc; |
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 is 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 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
in this example, the addition will result in an overflow. The resulting value is then zero-extended to fit into the 64-bit storage allocated by sll
.
In the following non-compliant code example, cBlocks is multiplied by 16 and the result is stored in the unsigned long long int alloc. The result of this multiplication can overflow because it is a 32 bit operation and the resulting value stored in alloc invalid.
void* AllocBlocks(size_t cBlocks) { if (cBlocks == 0) return NULL; unsigned long long alloc = cBlocks * 16; return (alloc < UINT_MAX) ? malloc(cBlocks * 16) : NULL; } |
On architectures where unsigned long long int is guaranteed to have 2x the number of bits as size_tupcast the variable used in the multiplication to a 64-bit value. This ensures the multiplication operation is performed
void* AllocBlocks(size_t cBlocks) { if (cBlocks == 0) return NULL; unsigned long long alloc = (unsigned long long)cBlocks*16; return (alloc < UINT_MAX) ? malloc(cBlocks * 16) : NULL; } |
The assumption concerning the relationship of unsigned long long int and size_t must be document in the header for each file that depends upon this assumption for correct execution.
Unsigned integers can be allowed to exhibit modulo behavior if and only if
Improper range checking can lead to buffer overflows and the execution of arbitary code by an attacker.