Stable kernels 2.6.27.27 and 2.6.30.2

With the recent changes this optimization is no longer performed, which--as a fix for a single obvious logic error in the code--will lead to less efficient code in general without solving the core issue, which is the failure to test for NULL before dereferencing a potentially-NULL pointer. It would make more sense to either guarantee that execution will not continue following a NULL dereference or classify all NULL dereferences as exploitable vulnerabilities (or both).

The reason that the kernel wants this option but userspace doesn't is because, in kernel space, an attacker might map something into address 0, so assuming that null pointer dereferences always crash is dangerous. In userspace, on the other hand, you've already been owned by the time someone maps something at address 0.

But examples abound. Simple one from http://lwn.net/Articles/342226/:

inline char foo(char *p) { if (p == 0) return 0; else return *p; }
char bar(char *p) { *p = 2; return foo(p); }
int main() { char c = 0; return bar(&c); }

I already see GCC bugzilla fill with complaints when it would no longer compile this (perfectly valid) piece of code with a redundant NULL pointer check...

Consider this: When a programmer writes a function, lets call it f(), it is good practice to validate all inputs and return an error code if they are not correct. If the programmer calls f() in a loop, and the compiler decides to inline f(), then these checks for parameters may be done repeatedly and cost significant time.

This is very important for C++ where inline functions are used more often than in C (eg when small functions are placed inside class definitions)

[Side note: in Java it is particularly important (for performance) to remove unneeded null pointer checks, because every pointer dereference implies a null pointer and array bounds check.]