...
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stddef.h> #include <assert.h> #include <limits.h> #include <inttypes.h> extern size_t popcount(uintmax_t); #define PRECISION(umax_value) popcount(umax_value) void func(signed int si_a, signed int si_b) { signed int result; signed long long tmp; assert(PRECISION(ULLONG_MAX) >= 2 * PRECISION(UINT_MAX)); tmp = (signed long long)si_a * (signed long long)si_b; /* * If the product cannot be represented as a 32-bit integer, * handle as an error condition. */ if ((tmp > INT_MAX) || (tmp < INT_MIN)) { /* Handle error */ } else { result = (int)tmp; } /* ... */ } |
The assertion fails if long long
has less than twice the width of int
. The PRECISION()
macro and popcount()
function are explained in INT35-C. Use correct integer precisions.
Compliant Solution
The following portable compliant solution can be used for on any conforming implementation, including those where this assertion fails:
...
Code Block | ||||
---|---|---|---|---|
| ||||
void func(signed long s_a, signed long s_b) { signed long result; if (s_b == 0) { /* Handle error */ } else { result = s_a / s_b; } /* ... */ } |
Compliant Solution
This compliant solution eliminates the possibility of divide-by-zero errors or signed overflow:
...
On Microsoft Visual Studio 2013, taking the remainder of LONG_MIN
by −1
results in abnormal termination on x86 and x64. On GCC/Linux, taking the remainder of LONG_MIN
by −1
produces a floating-point exception. However, on GCC 4.2.4 and newer, with optimization enabled, taking the remainder of LONG_MIN
by −1
yields the value 0
.
Compliant Solution
This compliant solution also tests the remainder operands to guarantee there is no possibility of an overflow:
...
The C Standard, 6.5.7 paragraph 4 [ISO/IEC 9899:2011], states
...
In almost every case, an attempt to shift by a negative number of bits or by more bits than exist in the operand indicates a bug (logic error). These issues are covered by INT34-C. Do not shift a negative number of bits or more bits than exist in the operand.
Noncompliant Code Example
This noncompliant code example can result in an unrepresentable value.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <limits.h> #include <stddef.h> #include <inttypes.h> extern size_t popcount(uintmax_t); #define PRECISION(umax_value) popcount(umax_value) void func(signed long si_a, signed long si_b) { signed long result; if ((si_a < 0) || (si_b < 0) || (si_b >= PRECISION(ULONG_MAX)) { /* Handle error */ } else { result = si_a << si_b; } /* ... */ } |
Compliant Solution
This compliant solution eliminates the possibility of overflow resulting from a left-shift operation:
...
Code Block | ||||
---|---|---|---|---|
| ||||
void func(signed long s_a) { signed long result = -s_a; /* ... */ } |
Compliant Solution
This compliant solution tests the suspect negation operation to guarantee there is no possibility of signed overflow:
...
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdatomic.h> atomic_int i; void func(int si_a) { atomic_init(&i, 42); atomic_fetch_add(&i, si_a); /* ... */ } |
Compliant Solution
This compliant solution tests the operands to guarantee there is no possibility of signed overflow. It loads the value stored in the atomic integer and tests for possible overflow before performing the addition. However, this code contains a race condition where i
can be modified after the load, but prior to the atomic store. This solution is only compliant if i
is guaranteed to only be access by a single thread. See CON43-C. Do not assume that a group of calls to independently atomic methods is atomic for more information.
...