Page History

Integer conversions, including both implicit and explicit (using a cast), must be guaranteed not to result in lost or misinterpreted data. This is particularly true for integer values that originate from untrusted sources and are used in any of the following ways:

• as an array index
• in any pointer arithmetic
• as a length or size of an object
• as the bound of an array (for example, a loop counter)
• as an argument to a memory allocation function
• in security-critical code

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. C99 Section 6.3.1.3 says

...

signed int si = INT_MIN;
unsigned int ui;
ui = (unsigned int)si;  /* cast eliminates warning */

...

signed long int sl = LONG_MAX;
signed char sc;
sc = (signed char)sl; /* cast eliminates warning */

...

unsigned long int ul = ULONG_MAX;
unsigned char uc;
uc = (unsigned char)ul;  /* cast eliminates warning */

...

Conversions from unsigned types with greater precision to signed types with lesser precision require only require the upper bounds to be checked.

...

INT31-EX1: C99 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, while the minimum range for int is -32—32,767 to +32,767. This means that 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—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 by using static assertions (see DCL03-C. Use a static assertion to test the value of a constant expression).

...

\[[Dowd 06|AA. C References#Dowd 06]\] Chapter 6, "C Language Issues" (Type Conversions, pp. 223-270)
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] 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," and [CWE ID	 197|http://cwe.mitre.org/data/definitions/197.html], "Numeric Truncation Error," and [CWE ID 681|http://cwe.mitre.org/data/definitions/681.html], "Incorrect Conversion between Numeric Types"
\[[Seacord 05a|AA. C References#Seacord 05]\] Chapter 5, "Integers"
\[[Viega 05|AA. C References#Viega 05]\] Section 5.2.9, "Truncation error," Section 5.2.10, "Sign extension error," Section 5.2.11, "Signed to unsigned conversion error," and Section 5.2.12, "Unsigned to signed conversion error"
\[[Warren 02|AA. C References#Warren 02]\] Chapter 2, "Basics"

...