3 ms·

It should be fine, but it isnt. The Linux kernel has had problems with this kind of code, because the flow control indicates that the dereferencing will happen

It should be fine, but it isnt. The Linux kernel has had problems with this kind of code, because the flow control indicates that the dereferencing will happen irregardless of the if statement. Its order independent. If the function had a "noreturn" qualifier, or an "else" that could tell the compiler that hitting the if statement will mean that the dereference never happens, then the compiler would not break this code. I dont want to sound like I'm showing off of or putting down your comment. Your comment is 100% reasonable. Its an example of how the spec is not reasonable, and it doesn't do what any reasonable person would expect.

saagarjha 6y ago
No, I meant what I said. The famous kernel “null pointer check removal” bug was in code of the form void foo(int *bar) { int baz = *bar; if (!bar) { return; } /* do stuff with baz */ } which you can see provably invokes undefined behavior if bar is NULL. In the case you provided where the dereference comes after a function call the compiler cannot optimize out the check unless it can prove that control flow returns, which you claim it does not (it exits). noreturn and such are there to improve these cases and make them explicit to the compiler, but in the absence of information it must be conservative as there are many ways for a function call to never return, one of which is exit(3). Optimizing this case would be incorrect (i.e. a compiler bug) and this happens to be one of the reasons why function calls often serve as a barrier to optimizations in C.
MauranKilom 6y ago
> If the function had a "noreturn" qualifier, or an "else" that could tell the compiler that hitting the if statement will mean that the dereference never happens, then the compiler would not break this code. If the compiler can't prove that the function returns, it's not allowed to assume that it does. I challenge you to cook up an example on godbolt.org that shows the behavior you claim. But take note of the difference between https://godbolt.org/z/sWYEYc https://godbolt.org/z/sWYEYc and https://godbolt.org/z/3E7hbz https://godbolt.org/z/3E7hbz

saagarjha 6y ago

No, I meant what I said. The famous kernel “null pointer check removal” bug was in code of the form void foo(int *bar) { int baz = *bar; if (!bar) { return; } /* do stuff with baz */ } which you can see provably invokes undefined behavior if bar is NULL. In the case you provided where the dereference comes after a function call the compiler cannot optimize out the check unless it can prove that control flow returns, which you claim it does not (it exits). noreturn and such are there to improve these cases and make them explicit to the compiler, but in the absence of information it must be conservative as there are many ways for a function call to never return, one of which is exit(3). Optimizing this case would be incorrect (i.e. a compiler bug) and this happens to be one of the reasons why function calls often serve as a barrier to optimizations in C.

MauranKilom 6y ago

> If the function had a "noreturn" qualifier, or an "else" that could tell the compiler that hitting the if statement will mean that the dereference never happens, then the compiler would not break this code. If the compiler can't prove that the function returns, it's not allowed to assume that it does. I challenge you to cook up an example on godbolt.org that shows the behavior you claim. But take note of the difference between https://godbolt.org/z/sWYEYc https://godbolt.org/z/sWYEYc and https://godbolt.org/z/3E7hbz https://godbolt.org/z/3E7hbz