...
The only integer type conversions that are guaranteed to be safe for all data values and all possible conforming implementations are conversions of an integral value to a wider type of the same signedness. Subclause The C Standard, 6.3.1.3 of the C Standard [ISO/IEC 9899:2011], says,
When a value with integer type is converted to another integer type other than
_Bool
, if the value can be represented by the new type, it is unchanged.Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.
Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
...
Code Block | ||||
---|---|---|---|---|
| ||||
#include <limits.h>
void func(void) {
unsigned long int u_a = ULONG_MAX;
signed char sc;
if (u_a <= SCHAR_MAX) {
sc = (signed char)u_a; /* Cast eliminates warning */
} else {
/* Handle error condition */
}
} |
Noncompliant Code Example (Signed to Unsigned)
...
Code Block | ||||
---|---|---|---|---|
| ||||
#include <limits.h> void func(void) { signed int si = INT_MIN; /* Cast eliminates warning unsigned*/ unsigned int ui = (unsigned int)si; /* Cast eliminates warning */ /* ... */ } |
Compliant Solution (Signed to Unsigned)
...
Code Block | ||||
---|---|---|---|---|
| ||||
#include <limits.h>
void func(void) {
unsigned long int u_a = ULONG_MAX;
unsigned char uc = (unsigned char)u_a; /* Cast eliminates warning */
/* ... */
} |
...
INT31-EX1: The C Standard defines minimum ranges for standard integer types. For example, the minimum range for an object of type unsigned short int
is 0 to 65,535, whereas the minimum range for int
is −32,767 to +32,767. Consequently, it is not always possible to represent all possible values of an unsigned short int
as an int
. However, on the IA-32 architecture, for example, the actual integer range is from −2,147,483,648 to +2,147,483,647, meaning that it is quite possible to represent all the values of an unsigned short int
as an int
for this architecture. As a result, it is not necessary to provide a test for this conversion on IA-32. It is not possible to make assumptions about conversions without knowing the precision of the underlying types. If these tests are not provided, assumptions concerning precision must be clearly documented, as the resulting code cannot be safely ported to a system where these assumptions are invalid. A good way to document these assumptions is to use static assertions . (See see DCL03-C. Use a static assertion to test the value of a constant expression).)
INT31-EX2: Conversion from any integer type with a value between SCHAR_MIN
and UCHAR_MAX
to a character type is permitted provided the value represents a character and not an integer.
...
Conversions to signed character types are more problematic.
The C Standard, subclause 6.3.1.3, paragraph 3, says, regarding conversions:
...
Furthermore, subclause 6.2.6.2, paragraph 2, says, regarding integer modifications:
If the sign bit is one, the value shall be modified in one of the following ways:
— the corresponding value with sign bit 0 is negated (sign and magnitude); — the sign bit has the value −(2M ) (two’s complement);
— the sign bit has the value −(2M − 1) (ones’ complement).
Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for ones’ complement), is a trap representation or a normal value. [See note.]
NOTE: Two's complement is shorthand for "radix complement in radix 2." Ones' complement is shorthand for "diminished radix complement in radix 2."
Consequently the Consequently the standard allows for this code to trap:
...
However, platforms where this code traps or produces an unexpected value seem to be are rare. According to The New C Standard: An Economic and Cultural Commentary by Derek Jones [Jones 2008]:
Implementations with such trap representations are thought to have existed in the past. Your author was unable to locate any documents describing such processors.
...
CVE-2009-1376 results from a violation of this rule. In version 2.5.5 of Pidgin, a size_t
offset is set to the value of a 64-bit unsigned integer, which can lead to truncation [xorl 2009] on platforms where a size_t
is interpreted implemented as a 32-bit unsigned integer. An attacker can execute arbitrary code by carefully choosing this value and causing a buffer overflow.
...
CERT C Secure Coding Standard | DCL03-C. Use a static assertion to test the value of a constant expression INT18-C. Evaluate integer expressions in a larger size before comparing or assigning to that size |
CERT C++ Secure Coding Standard | INT31-CPP. Ensure that integer conversions do not result in lost or misinterpreted data |
CERT Oracle Secure Coding Standard for Java | NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data |
ISO/IEC TR 24772:2013 | Numeric Conversion Errors [FLC] |
MISRA C:2012 | Rule 10.1 (required) |
MITRE CWE | CWE-192, Integer coercion errorCoercion Error CWE-197, Numeric truncation errorTruncation Error CWE-681, Incorrect conversion Conversion between numeric typesNumeric Types |
Bibliography
[ | Derek Jones 2013]Section 6.2.6.2, "Integer types" | [Dowd 2006] | Chapter 6, "C Language Issues" ("Type Conversions," pp. 223–270) |
[ISO/IEC 9899:2011] | Subclause 6.3.1.3, "Signed and Unsigned Integers" | ||
[Jones 2008] | Section 6.2.6.2, "Integer Types" | ||
[Seacord 20132013b] | Chapter 5, "Integer Security" | ||
[Viega 2005] | Section 5.2.9, "Truncation Error" Section 5.2.10, "Sign Extension Error" Section 5.2.11, "Signed to Unsigned Conversion Error" Section 5.2.12, "Unsigned to Signed Conversion Error" | ||
[Warren 2002] | Chapter 2, "Basics" | ||
[xorl 2009] | "CVE-2009-1376: Pidgin MSN SLP Integer Truncation" |
...