That might seem a bit aggressive and risky but it's not rare to write funky macro code where you hope the compiler will be clever enough to get rid of the cruft.
One case I can come up with is if you have some code that does, say:
int foo(int a) {
int next = a + 1;
return increment(a);
}
int increment(int a) {
if (a == INT_MAX) {
return 0;
}
return ++a;
}
Now, if this is an actual coding error, that's nasty. If however I wrote foo that way because I'm sure that "a" is a small integer with no risk of overflow then it's a fine optimization.
If overflow is implementation defined then the optimization is illegal, in case of overflow "next" is implementation defined but the test should run.
Note that here I put the "next = a + 1" before the call to increment, but it would still be a valid optimization if the call was done after the call to increment (with the original value of a, that is):
int foo(int a) {
int next, ret;
ret = increment(a);
next = a + 1;
return ret;
}
To me that seems really reckless! If you need that note, make it a compiler pragma or something, rather than trying to sneak it in by repurposing some existing code.
Now if overflow were implementation-defined, the compiler would have to assume that INT_MAX + 1 wraps to INT_MIN (say). So as written, the "if (a == INT_MAX)" line would stay. That's what I would expect to happen on reading the code, and I'm confident that that's what most reasonable people would expect too.
If you want to skip the "if (a == INT_MAX)" check, just take it out.
I'm sure optimizations like this are important for squeezing a few extra percent out of the standard benchmarks. But for most ordinary programmers they're just a minefield you have to tiptoe carefully around.
This is a very simple example of course, but maybe this "increment" code is actually used in many other parts of the codebase where the test actually makes sense.
It's not rare for instance to start a C function with "if (param == NULL) return;", just in case. If the compiler inlines the function and sees that the caller dereferences "param" it can assume that it's not null and remove the test.
But you're right that it makes it easy to shoot yourself in the foot. I remember a strange bug in the linux kernel source that was "hidden" by such an optimization, the code looked something like that:
int bar(somestruct *ptr) {
int somevalue = ptr->val;
if (ptr == NULL) {
return -EINVAL;
}
// Rest of the function here
}
It can take a while to debug code like that.
Not all UB can be detected at compile time, but when it can be detected, it should be flagged to the user.
int f(int *x)
{
if (x == NULL) return 0;
return *x;
}
int g(int *p)
{
return (*p) + f(p);
}In the accompanying Rationale, the committee explicitly calls out places where the standard intentionally diverged from existing practice; they did not do so for UB. They thought “the most serious semantic change” was mandating value-preserving rather than unsigned-preserving integer promotion.
For instance, the following code :
for(i = 0; i<max; i++){
for(j = i; j<max; j=j*2){
//do something
}
}
That's not the whole picture though. The standard actually says that anything can happen in undefined cases.
> However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).
The standard doesn't specify what the resulting program should do at all. It's equally valid to e.g. emit code that fails gracefully instead totally ignoring the undefined branch.
If you were to try to write a program that accurately detected whether the given input is a meaningful C program, you'd have to solve the Halting Problem (and more, once you take IO into account.) Thus undefined behavior must exist in the places where your program is syntactically valid but has no definite semantics. (And you can't enumerate all of these places in a Turing complete language.)
Not even a C compiler will be able to tell you if it actually has been given C code; all it can say is "I parsed it, and here're some semantics for it."
It's just C whose actual behavior is unspecified (and, because the standard is outright perverse, makes the entire program's behavior undefined) by the standard and, if you are especially lucky, explicitly defined by the particular C implementation. But maybe not even then.
> That's not the whole picture though. The standard actually says that anything can happen in undefined cases.
Well, that's right the standard says the compiler can do anything they want, including erasing all data from your hard drive or summoning a demon in your nose [1], but in practice I've never seen any compiler attempt such things.
What compilers usually do with UB is assuming it will never happen and use this invariant as an optimization hint.
Reminds me of the Java binary search bug: https://research.googleblog.com/2006/06/extra-extra-read-all...
I think the correct code here would be something like:
for (j = i; j <= (max+1)/2; j = j*2)
Why even bother writing C if you all you achieve is Java, PyPy or JavaScript level in term of performance ?
Some CPU ABI even have instructions which, when used with certain operands, are undefined. For instance the ARM Thumb "BL" instruction is encoded as two successive "pseudo-instructions", IIRC if you break the pair the behaviour is undefined. There are other instructions which are either undefined of implementation-defined, in particular instructions which attempt to load or store the PC register.
C takes it a bit over the top, for instance overflow doesn't have to be undefined behaviour (it could be left as implementation-defined for instance, which is a lot less nasty).