To summarize at least one of them, the compiler doesn't really see it as “detecting undefined behavior and optimizing accordingly”. It sees it as doing the right thing for all defined behaviors. The sort of imprecise analysis it does lead it to consider plenty of possible undefined behaviors, many of which cannot happen in real executions. It ignores these as a matter of fact, but reporting them would not tell the programmer anything it doesn't know, and would be perceived as noise.
On the example for (int i=1; i==0; i++) …, the compiler does not infer that i eventually overflows (undefined behavior). It infers that i is always positive, and thus that the condition is always false.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Signed integers have some weirdness attached. The number that's one followed by all zeroes in binary (INT_MIN in limits.h) is defined as negative, because the sign bit is set. But, the rules for 2's complement arithmetic predict that -INT_MIN == INT_MIN. So it's not a normal number.
int abs_s(int x) {
assert(x != INT_MIN);
return (x >= 0) ? x : -x;
}(On that note: Are there even machines left to write code for that don't use two's complement? Or 8 bits per byte?)
#include <limits.h>
#include <stdio.h>
void main(void) {
int x = INT_MIN;
printf("INT_MIN = %d\n", x);
printf("INT_MIN * -1 = %d\n", x * -1);
printf("INT_MIN / -1 = %d\n", x / -1);
} $ gcc -std=c99 -S intmin.c -o intmin.s
$ clang -std=c99 -S intmin.c -o intmin.sc
$ grep -i div intmin.s*
intmin.sc: idivl %esi
$ clang --version
Debian clang version 3.5-1~exp1 (trunk) (based on LLVM 3.5)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -o intmin_c -std=c99 intmin.c
$ ./intmin_c
INT_MIN = -2147483648
INT_MIN * -1 = -2147483648
Floating point exception
$ gcc --version
gcc-4.7.real (Debian 4.7.2-5) 4.7.2
(...)
$ gcc -o intmin -std=c99 intmin.c
$ ./intmin
INT_MIN = -2147483648
INT_MIN * -1 = -2147483648
INT_MIN / -1 = -2147483648
$ tcc -v
tcc version 0.9.25
$ tcc -run intmin.c
INT_MIN = -2147483648
INT_MIN * -1 = -2147483648
Floating point exception
$ cat intmin.c
#include <limits.h>
#include <stdio.h>
int main(void) { // Change from void to int for c99
int x = INT_MIN;
printf(" INT_MIN = %d\n", x);
printf("INT_MIN * -1 = %d\n", x * -1);
printf("INT_MIN / -1 = %d\n", x / -1);
return 0; // return 0 - c99
}
It's also a good example of how undefined behavior allows for optimizations. The compiler is able to evaluate your expression at compile time rather than emitting a division instruction, even though this changes how the program behaves.
C sure is fun.
if(x + 1 < x)
...
C99 defines int8_t, if it exists, to be a 2's complement signed integer of exactly 8 bits. Same for 16, 32, etc. The standard could very well define behavior on overflow for these (that is, turn them into actual types instead of typedefs), and leave int, long, etc alone. I think this would be a viable, realistic, solution. Integer conversions would probably still be a pain, though.
Besides, fixing spammy warnings shouldn't be more difficult than fixing actual spam! I mean, common, with spam you have intelligent adversaries and compilers haven't reached that level. Not yet, anyway...
For a trivial NULL-related example, the standard C free() function does a NULL check on its parameter. free(NULL) is legal and does nothing. A naive "does this check for NULL after dereferencing the pointer?" checker would therefore warn for this code:
printf("the pointer's value is %d", *p);
free(p);
But! You made a good point, and it would apply to a function that did a null-check which was inlined. It's easy for us to imagine a function which 1) does a null-check, 2) gets inlined, and 3) is used in places in the code which dereference the pointer before calling the function.
free(ptr);
printf("after free, it contains %d\n", *ptr);
As a somewhat trivial example:
#include <stdio.h>
#include <string.h>
int main() {
printf("%lu\n", strlen("Test"));
return 0;
}
; Line 5
push 4
push OFFSET ??_C@_04OJNJKCBM@?$CFlu?6?$AA@
call _printf
add esp, 8
; Line 6
xor eax, eax
; Line 7
ret 0
You'll notice in a lot of cases that the exploitation of UB looks different for the same cases with different compilers or even compiler versions. This is because the compiler doesn't see »Oh, UB, I can optimise that« but rather »In this case I can do this which remains valid for all defined cases«.
Also, as others have pointed out, even if the compiler would emit a warning, it would be way too much noise because such things happen all the time.
How so? For example, this code:
printf("the pointer's value is %d", *p);
free(p);
Can you give an example of useful code that contains unreachable lines before macroexpansion and inlining? What's wrong with emitting a warning so the programmer can delete the useless line?
> You'll notice in a lot of cases that the exploitation of UB looks different for the same cases with different compilers or even compiler versions.
That's OK. The problem is with each individual compiler deleting code without warning. If compiler X deletes a line of my code, then it should warn me about it. If compiler Y doesn't delete that line, it doesn't have to warn me.
Issuing an error or warning about this would flood stuff with warnings due to inlining/macros, you name it.
This happens all the time.
Basically, distinguishing between the things that are accidents, and things that are on purpose and expected to be optimized away, is very very very hard.
/* Assumes you have a valid foo */
int printfoo(struct foo *bar)
{
/* Print the main part of our foo */
printf("First field: %d\n", bar->first);
/* Get the substructure value */
int foosub = get_foosub(bar);
printf("Second field: %d\n", bar->second);
}
/* Doesn't assume you have a valid foo */
int get_foobsub(struct foo *bar)
{
if (bar != NULL)
return bar->second;
assert();
}
If you know that p is not NULL, the code is just fine. The compiler has to compile it.
Kent Dybvig's classic response to "Who writes that kind of code?" is "Macros do." Inlining has much the same effect as macros.
These dummy tests can happen if you have a lot of macros for example. It still valid C code as long as p is not NULL. A compiler generating an error on this particular example wouldn't be a correct C compiler.
The compiler can reject this code if it can prove that p can be NULL, but in many case that's impossible at compile time.
I agree that a warning would be nice though.
edit: clarity.
int Successor(int x) { return x + 1; }
How about this simple function?
int Divide(int x, int y) { return x / y; }
(Never mind why you're writing such simple functions. Imagine they do something more complex and just do the division or addition or whatever as part of their work.)
Here's a fun one:
void StrClear(char *str) {
memset(str, 0, strlen(str));
}
Many real, practical, production-worthy C functions will invoke undefined behavior with some inputs. Turning undefined behavior into a compile-time error will cause virtually all C code to not compile.
Well, the compiler should warn you if you try to pass a (char const ＊) to a function expecting a (char ＊). Use -Wwrite-strings to make string literals have type (char const[]) rather than (char[]).
The simple answer is "the halting problem".
If you can build a compiler that knows with certainty what runtime behavior would result from any program (including whether undefined behavior occurs), then you could solve the halting problem, but the halting problem is provably undecidable. So such a compiler cannot exist even in theory for the general case.
Yes, you can template-match a bunch of special cases, but the user can always write new code that doesn't match any of your "known to be defined behavior" patterns but still executes only defined behavior. Guaranteed!