Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: split two multiply CS's into two CS sections

...

Code Block
bgColor#ccccff
langc
#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
bgColor#FFcccc
langc
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
bgColor#FFcccc
langc
#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
bgColor#FFcccc
langc
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
bgColor#FFcccc
langc
#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.

...