Why? Why is this OK? You say doing "something reasonable" is hard, but it obviously doesn't include entirely ignoring code I wrote. That's basically saying "I see you did something weird there, but going to assume the rest of your code and ask the libraries you link to are perfectly standard-compliant, which lets me generate faster code here. I'm so smart!"
Default safe, not fast, wherever possible.
Here's a quick bad example:
int computation(int *a, int *b) {
if(a == NULL && b == NULL) return 0;
if(a == NULL) return *b;
if(b == NULL) return *a;
return ...something with *a and *b...;
}
...elsewhere...
int a[1024];
int b[1024];
...fetch data into a and b...
int c[1024];
for(int i = 0; i < 1024; i++)
c = computation(a + i, b + i);
Consider a programmer who feels it's clearer to dereference a and b once, rather than writing using * a and * b in the complicated math after the preliminary checks. And because they don't want to rely on C99 or distract by opening a new block, they put the conversion at the top of the function. Oh, and the new guy decided to add the "missile launch" code here.
int computation(int *ptr_a, int *ptr_b) {
int val_a = *a, val_b = *b;
if(ptr_a == NULL && ptr_b == NULL) return 0;
if(ptr_a == NULL) return val_b;
if(ptr_b == NULL) return val_a;
launch_missiles(); /* OK to put this here? */
return ...something with val_a and val_b...;
}
I'm fine with a literalist compiler that produces code that crashes when it immediately tries to dereference a NULL pointer, with one that produces code that does the safety checks but defers the load, but even if allowed by the spec[1] I don't think it's good behavior for a compiler to silently omit the safety checks and launch the missiles when passed a NULL.
[1] Is this undefined behavior according to the spec? I consider myself an expert C programmer, and I think it's undefined in C99, but I wouldn't bet that I've correctly understood the issues for the other dialects of C, muchless C++. Is a conforming compiler "allowed" to skip the safety checks and launch the missiles? I don't know, and thus defensively wouldn't write the code like this, but it would be nice to think that long-standing mission-critical code written by others won't suddenly stop working with a new release of the optimizing compiler.
I'm pretty sure your snippet invokes nasal demons in all dialects. Dereferencing NULL is a pretty classic case where anything can happen once you do it. "Calling launch_missiles even though you don't want it to happen" is a subset of "anything," of course.
Consider what happens if you rearrange that example a bit, though. Let's say it's more like this:
int computation(int *ptr_a, int *ptr_b) {
if(ptr_a == NULL && ptr_b == NULL) return 0;
if(ptr_a == NULL) return val_b;
if(ptr_b == NULL) return val_a;
launch_missiles(); /* OK to put this here? */
return ...something with val_a and val_b...;
}
int otherComputation(int *ptr_a, int *ptr_b) {
int val_a = *ptr_a, val_b = *ptr_b;
int intermediate = computation(ptr_a, ptr_b);
return ...something with val_a, val_b, and intermediate....;
}
That's really what I'm getting at. There are clear examples where it's bad to assume undefined behavior cannot happen and optimize away checks. But there are also clear examples where it's exactly what you want to do. Can the optimizer reliably distinguish between these cases?
I think the best answer is to have tools available like the undefined behavior sanitizer which can catch these problems at runtime. You want the optimizer to make your code as fast as it legally can. Trying to tone it down is going to be error-prone, and safety checks that can't be counted on are dangerous. You might end up just moving the problem around: instead of code suddenly being optimized out because the compiler proved it can't run without invoking undefined behavior, you'll have code suddenly being optimized out because something changed that made the compiler think you intended it. By checking at runtime, you recast the problem from "does the programmer intend to pass in values which will result in undefined behavior?" to "does this code actually get called with such values?" That's way easier to check, should have zero false positives, and should have as few false negatives with good test coverage.
I'm pretty sure your snippet invokes nasal demons in all dialects. Dereferencing NULL is a pretty classic case where anything can happen once you do it.
Is the dereferencing itself undefined in all dialects, or is it only undefined if one later "evaluates" the dereferenced value? Or do some define evaluation differently? For example (to my surprise) a comment by 'lkasndasd' on the corresponding Reddit thread points out that &* ptr is never undefined behavior in C, since the address operator and the dereference operator cancel out even (explicitly) if ptr is NULL:
6.5.3.2 Unary arithmetic operators, Semantics, paragraph 3:
The unary & operator yields the address of its operand.
[...] If the operand is the result of a unary * operator,
neither that operator nor the & operator is evaluated and
the result is as if both were omitted, except that the
constraints on the operators still apply and the result is
not an lvalue.
and footnote 102:
Thus, &*E is equivalent to E (even if E is a null pointer) [...]
I'm pretty sure the dereference is immediately UB (other than the case you quote here). Consider that when optimizations are off, that line will probably immediately execute a load instruction, generating a segfault.
nate@haswell:~/tmp$ cat deref.c
/* gcc -fno-inline -O3 -g -Wall deref.c -o deref */
/* (or as desired to show particular outcome) */
#include <stdio.h>
#include <stdlib.h>
void deref_and_print(int *ptr) {
int i = *ptr; /* undefined behavior if ptr is NULL */
if (ptr == NULL) printf("NULL\n");
else printf("%d\n", i);
}
int main(int argc, char **argv) {
int *ptr = NULL;
if (argc <= 1) {
printf("Usage: %s [arg]\n", argv[0]);
printf(" Demonstrates undefined behavior if 'arg'");
printf(" is not a positive integer\n");
exit(1);
}
int i = atoi(argv[1]);
if (i > 0) ptr = &i;
deref_and_print(ptr);
exit(0);
}
If you want to use undefined behavior to elide the NULL checks, consider:
int computation(int *a, int *b) {
if(a == NULL && b == NULL) return 0;
if(a == NULL) return *b;
if(b == NULL) return *a;
return ...something with *a and *b...;
}
...elsewhere...
int *a = malloc(sizeof(*a) * 1024);
int *b = malloc(sizeof(*a) * 1024);
for(int i = 0; i < 1024; i++) {
a[i] = i;
b[i] = i * 2;
}
int c[1024];
for(int i = 0; i < 1024; i++)
c = computation(a + i, b + i);
My pet one of these is "this (by which I mean the pointer of the current object, not the demonstrative pronoun ;P) cannot be NULL". clang has started outputting messages to me that it will soon stop honoring my checks that this is not NULL, entirely removing them from my code, even in cases where this actually can be NULL and the code is not guaranteed to crash in some predictable way. If the language helped me guarantee that this was never NULL, that would be one thing, but it doesn't, and the compiler has decided, for reasons I don't understand, to remove one of the only mechanisms I currently have to detect, log, and mitigate.
References are a similar thing: it would be one thing if dereferencing a NULL pointer caused my program to crash, so clearly the NULL checks on the address of a reference are not useful. But it doesn't work like that. Dereferencing a NULL pointer returns a NULL reference that doesn't cause a crash until the pointer is used. This is actually kind of similar to weakly-linked symbols, where a declared function can have its address be NULL. This is a feature of linkers and the compiler and puts people in a regime where it sometimes makes a lot of sense to compare the address of an expression with NULL.
But somehow, this one is special; so special that even though the compiler knew what I wanted so clearly it felt the need to spit out a paragraph of nonsense at me to tell me that I should remove this check, and that it really didn't want this check in my code in the first place, if I was stupid enough to leave it in my code it was going to delete it for me. I just... I don't understand how that is even remotely reasonable behavior. If it was a side effect of the optimizer and there was no way to surmise what I wanted, then that would be one thing: but the compiler is detecting my code, and demanding that either I remove it myself or it will take control? WTF.
That is not the mantra of C. C is designed to be fast and almost all decisions will err towards speed rather than safety.
If you want a safety first language, check out Rust.
For every example like this, where the programmer wants a NULL check to be done even when the value "can't be NULL," there's an opposite example where the programmer wants a NULL check to be elided because the value actually can't be NULL.
Taking advantage of undefined behavior isn't done because compiler writers are sadists who enjoy writing perverse implementations which rely on the letter of the law. It's done because it allows the compiler to generate better, faster code.
I think a lot of the trouble is that too many programmers learn C in a completely ad-hoc, informal fashion and never take the time to actually become familiar with the fundamentals of the language. People simply don't know how the language is specified, what operations are legal and what operations aren't, why there are illegal operations that the compiler won't (and can't) warn you about, etc.
C is definitely a dangerous language and is a difficult language to use well. But that's all the more reason people who plan to use it need to ensure they understand it.
More mandatory reading: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...