ansaurus

Question

Integer overflow and undefined behavior.

Answer 1

+2 A:

The undefined behavior bits in the specification involve some compiler optimization. For example:

if (a > 0 && b > 0) {
    if ( a + b <= 0 ) {
       // this branch may be optimized out by compiler
    } else {
       // this branch will always run
    }
}

Modern C compilers are not that simple, it do lots of guessing and optimization.

J-16 SDiZ 2010-10-16 10:24:55

Good point, but this only means that the C compiler won't help you detect it.

ruslik 2010-10-16 10:40:40

@J-16 SDiZ another point: while compiler would be able to detect this arithmetic condition, some bit operations would be able to fool it so that the condition won't be optimized out. Also, as suggested by nategoose, we could just declare the sum as `volatile`.

ruslik 2010-10-16 13:12:16

This is not a valid use of the `volatile` keyword. If it works, it's a result of a specific implementation, not specified behavior. I.e. it's still undefined behavior.

R.. 2010-10-16 16:16:48

Answer 2

+1 A:

Although most modern CPUs use 2's complement, and integer overflow results in predictable modulo wraparound, this is by no means universal - to keep the language sufficiently general that it can be used on the widest range of architectures it's better to specify that integer overflow is UB.

Paul R 2010-10-16 10:31:35

Any cpu is twos complement if your compiler simply omits generating the useless signed arithmetic opcodes and uses the unsigned ones for both signed and unsigned types. This may incur minor performance losses when making comparisons (for instance, now `x<-1` requires 2 machine-level comparisons instead of just 1), but I for one would still prefer it that way.

R.. 2010-10-16 16:19:59

@R: 2's complement isn't the only issue though - e.g. some CPUs (DSPs, for example) have saturating arithmetic rather then modulo arithmetic.

Paul R 2010-10-16 16:23:29

@Paul: Modular arithmetic is required for supporting unsigned types anyway... if your machine doesn't have it I guess you have to implement it. One approach might be using the top bit as padding and zeroing it after each operation.

R.. 2010-10-16 16:46:59

Answer 3

A:

I think your assumption 1) that this can be switched off for any given processor has been false on at least one important historical architecture, the CDC, if my memory is correct.

Jens Gustedt 2010-10-16 12:08:30

This one is really old. I'd rather handle these cases with `#ifdef` .

ruslik 2010-10-16 13:13:16

@ruslik: The question is not **how** to handle this, `#ifdef` is just one way among other to avoid UB. But you see, as you say yourself, you would handle this somehow.

Jens Gustedt 2010-10-16 14:27:53

@Jens backwards compatibility has its limits. In this case I'd rather prefer to write buggy, but simple code.

ruslik 2010-10-16 15:08:04

@ruslik: sure your mileage may vary. Certainly depends if you write your code for yourself or if you expect it to end up in a library or so. I find all this fuss that we have gone through (and still go) with 32 vs. 64 bit portability a real shame for the whole profession. And we will see this again for the next step. So, no, I for myself I try to stick to the standards.

Jens Gustedt 2010-10-16 15:42:20

The assumption that trapping can be switched off is correct, because, as the implementor of the compiler, you can simply choose never to generate signed-arithmetic opcodes and always use the clean/safe unsigned ones. Then you get twos complement for free at the same time.

R.. 2010-10-16 16:21:17

Answer 4

+1 A:

While the historical reason signed overflow was specified as undefined behavior was probably these bogus legacy representations (ones complement/sign-magnitude) and overflow interrupts, the modern reason for it to remain undefined behavior is optimization. As J-16 SDiZ hinted at, the fact that signed overflow is undefined behavior allows the compiler to optimize out some conditionals whose algebraic truth (but not necessarily representation-level truth) are already established by a previous branch. It may also allow the compiler to algebraically simplify some expressions (especially those involving multiplication or division) in ways that could give different results than the originally-written order of evaluation if a subexpression contains an overflow, since the compiler is allowed to assume that overflow does not happen with the operands you've given it.

The other huge example of undefined behavior for the purpose of permitting optimization is the aliasing rules.

R.. 2010-10-16 16:28:39

ansaurus

tags:

views:

answers:

Integer overflow and undefined behavior.

related questions