Narrower arithmetic types can be cast to wider types without any effect on the magnitude of numeric values. However, whereas integer types represent exact values, floating-point types have limited precision. The C Standard, 126.96.36.199 paragraph 2 [ISO/IEC 9899:2011], states
When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined. Results of some implicit conversions may be represented in greater range and precision than that required by the new type (see 188.8.131.52 and 184.108.40.206).
Conversion from integral types to floating-point types without sufficient precision can lead to loss of precision (loss of least significant bits). No runtime exception occurs despite the loss.
Noncompliant Code Example
In this noncompliant example, a large value of type
long int is converted to a value of type
float without ensuring it is representable in the type:
For most floating-point hardware, the value closest to
1234567890 that is representable in type
1234567844; consequently, this program prints the value
This compliant solution replaces the type
float with a
double. Furthermore, it uses an assertion to guarantee that the
double type can represent any
long int without loss of precision. (See INT35-C. Use correct integer precisions and MSC11-C. Incorporate diagnostic tests using assertions.)
On the same implementation, this program prints
0, implying that the integer value
1234567890 is representable in type
double without change.
Conversion from integral types to floating-point types without sufficient precision can lead to loss of precision (loss of least significant bits).
|Supported: Astrée keeps track of all floating point rounding errors and loss of precision and reports code defects resulting from those.|
MISRA C 2004 Rule 10.x (needs investigation)
|LDRA tool suite|
|435 S||Fully implemented|
Implicit conversions from integral to floating type which may result in a loss of information shall not be used
|Polyspace Bug Finder|
|CERT-C: Rule FLP36-C||Checks for precision loss in integer to float conversion (rule fully covered)|
1260, 1263, 1298, 1299, 1800,
1802, 1803, 1804, 4117, 4435,
Key here (explains table format and definitions)
|CERT C Secure Coding Standard||DCL03-C. Use a static assertion to test the value of a constant expression||Prior to 2018-01-12: CERT: Unspecified Relationship|
|CERT Oracle Secure Coding Standard for Java||NUM13-J. Avoid loss of precision when converting primitive integers to floating-point||Prior to 2018-01-12: CERT: Unspecified Relationship|
|[ISO/IEC 9899:2011]||Subclause 220.127.116.11, "Real Floating and Integer"|