I'm currently using a library that uses code like
T& being_a_bad_boy() { return *reinterpret_cast<T*>(0); }
to make a reference to a T without there actually being a T. This is undefined behavior, specifically noted to be unsupported by the standard, but it's not an unheard of pattern.
I am curious if there are any examples or platforms or usages that show that in practice this can cause problems. Can anyone provide some?
Dereferencing a null pointer always results in undefined behavior and can cause crashes. If the compiler finds a pointer dereference, it treats that pointer as nonnull. As a result, the optimizer may remove null equality checks for dereferenced pointers.
Null dereferencingBecause a null pointer does not point to a meaningful object, an attempt to dereference (i.e., access the data stored at that memory location) a null pointer usually (but not always) causes a run-time error or immediate program crash. In C, dereferencing a null pointer is undefined behavior.
According to ISO C++, dereferencing a null pointer is undefined behaviour.
Dereferencing a null pointer is undefined behavior. On many platforms, dereferencing a null pointer results in abnormal program termination, but this is not required by the standard.
Classically, compilers treated "undefined behavior" as simply an excuse not to check for various types of errors and merely "let it happen anyway." But contemporary compilers are starting to use undefined behavior to guide optimizations.
Consider this code:
int table[5]; bool does_table_contain(int v) { for (int i = 0; i <= 5; i++) { if (table[i] == v) return true; } return false; }
Classical compilers wouldn't notice that your loop limit was written incorrectly and that the last iteration reads off the end of the array. It would just try to read off the end of the array anyway, and return true
if the value one past the end of the array happened to match.
A post-classical compiler on the other hand might perform the following analysis:
true
.i = 5
, the code performs undefined behavior. Therefore, the case i = 5
can be treated as unreachable.i = 6
(loop runs to completion) is also unreachable, because in order to get there, you first have to do i = 5
, which we have already shown was unreachable.true
. The compiler would then simplify this function to
bool does_table_contain(int v) { return true; }
Another way of looking at this optimization is that the compiler mentally unrolled the loop:
bool does_table_contain(int v) { if (table[0] == v) return true; if (table[1] == v) return true; if (table[2] == v) return true; if (table[3] == v) return true; if (table[4] == v) return true; if (table[5] == v) return true; return false; }
And then it realized that the evaluation of table[5]
is undefined, so everything past that point is unreachable:
bool does_table_contain(int v) { if (table[0] == v) return true; if (table[1] == v) return true; if (table[2] == v) return true; if (table[3] == v) return true; if (table[4] == v) return true; /* unreachable due to undefined behavior */ }
and then observe that all reachable code paths return true
.
A compiler which uses undefined behavior to guide optimizations would see that every code path through the being_a_bad_boy
function invokes undefined behavior, and therefore the being_a_bad_boy
function can be reduced to
T& being_a_bad_boy() { /* unreachable due to undefined behavior */ }
This analysis can then back-propagate into all callers of being_a_bad_boy
:
void playing_with_fire(bool match_lit, T& t) { kindle(match_lit ? being_a_bad_boy() : t); }
Since we know that being_a_bad_boy
is unreachable due to undefined behavior, the compiler can conclude that match_lit
must never be true
, resulting in
void playing_with_fire(bool match_lit, T& t) { kindle(t); }
And now everything is catching fire regardless of whether the match is lit.
You may not see this type of undefined-behavior-guided optimization in current-generation compilers much, but like hardware acceleration in Web browsers, it's only a matter of time before it starts becoming more mainstream.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With