##### Page tree
Go to start of banner

# INT16-C. Do not make assumptions about representation of signed integers

Although many common implementations use a two's complement representation of signed integers, the C Standard declares such use as implementation-defined and allows all of the following representations:

• Sign and magnitude
• Two's complement
• One's complement

This is a specific example of MSC14-C. Do not introduce unnecessary platform dependencies.

## Noncompliant Code Example

One way to check whether a number is even or odd is to examine the least significant bit, but the results will be inconsistent. Specifically, this example gives unexpected behavior on all one's complement implementations:

```int value;

if (scanf("%d", &value) == 1) {
if (value & 0x1 != 0) {
/* Take action if value is odd */
}
}
```

## Compliant Solution

The same thing can be achieved compliantly using the modulo operator:

```int value;

if (scanf("%d", &value) == 1) {
if (value % 2 != 0) {
/* Take action if value is odd */
}
}
```

## Risk Assessment

Incorrect assumptions about integer representation can lead to execution of unintended code branches and other unexpected behavior.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

INT16-C

Medium

Unlikely

High

P2

L3

### Automated Detection

 Tool Version Checker Description Astrée 19.04 bitop-type Partially checked LDRA tool suite 9.7.1 50 S, 120 S Partially Implemented Parasoft C/C++test 10.4.2 CERT_C-INT16-a Bitwise operators shall only be applied to operands of unsigned underlying type PRQA QA-C 9.7 2940, 2941, 2942, 2943, 2945, 2946, 2947, 2948 RuleChecker 19.04 bitop-type Partially checked

1. If you check subtraction under INT32-C. Ensure that operations on signed integers do not result in overflow you can find another example of a twos' complement solution.

1. I'd say this rule is now complete.

2. I'm beginning to suspect this rec is a variant of
INT14-C. Avoid performing bitwise and arithmetic operations on the same data

However, the NCCE doesn't violate INT14-C only because nothing else is done with the variable; it is merely input and then a bitwise operation is performed. Sort of a corner case not covered by INT14-C. So this rec is still valid on its own (outside INT14-C)

I do think this rec is unenforceable, however, because you can't infer that the programmer assumes 2s-complement whenever they perform a bitwise op.

3. If value is -3 then this result is wrong. This should be written as (value % 2 != 0).

1. Huh? When is value ever -3?

4. I think Yusuke is referring to INT10-C: Never assume the result of % is nonnegative.  If value (of type int) is -3, value % 2 could be -1.

1. Agreed, I fixed the code as as suggested.