Toughest bug/war stories

[bithub]

except that foo[i] is not a single sequence point, but 2 as is foo[i++].

I don't think you know what a sequence point is.

[laserlight]

Strictly, the behavior is unspecified, not undefined.

I stand corrected.

Exactly what behaviour are you two talking about? If you are talking about the snippet from post #12, then the behaviour really is undefined, but if you are talking about order of evaluation in general, then the behaviour is unspecified.

[Mario F.]

It's irrelevant abachler.

What matters is not foo[i++], but i = foo[i++]. The standard defines you are free to swap "sequence points" depending on your needs.


laserlight: It's in fact order of evaluation in general. That's the context of what brewbuck quoted from me.

[brewbuck]

Instead, you can expect a compiler to behave predictably. That's what they do best. What this does not mean however is that one can (or has the ability for that matter) to predict how the compiler will behave.

The compiler should be deterministic, but it isn't always easy to look at an expression and predict what will happen. For instance, the order in which subexpressions are evaluated may depend on things like register pressure, which you really can't discern. Changing some seemingly unrelated code on a previous or subsequent line may change the evaluation of an intervening expression, simply because the allocation of registers has changed.

[CornedBee]

Undefined behavior is always clearly defined by the implementation (the combination of compiler and CPU). The same code will always compile to the exact same machine code. There's nothing undefinable about compilers.

It's true that non-determinism in compilers is usually treated as a bug. Nevertheless, it happens, e.g. in LLVM/Clang we've had several bugs where some data structure (a hash or tree, usually) was sorted according to pointer values - and was thus extremely prone to change in face of the slightest change in the input. In the most recent incarnation, for example, this would change the order in which some functions were emitted in the object file. This can actually make a difference in, say, application startup performance, as the OpenOffice.org and Mozilla projects have discovered.

The other issue with undefined behavior is that optimizers tend to treat it in unpredictable ways. The effect? Internal state of the optimizer can completely change the way a statement is treated, i.e. completely unrelated code changes (in a different function, a different module even if using LTO) can change the way the statement is compiled.

Finally, undefined behavior in the C++0x execution model can be completely undefined: C++0x specifies multiple threads, and thus clearly defines what a race condition is. Programs containing race conditions are undefined, and have fun trying to duplicate the environment closely enough to get guaranteed identical runs from such programs.