3 ms·

> That's basically how compiler writers treat undefined behavior - just assume it doesn't happen. Yes, but this phrase is ambiguous. What it is meant to refer

> That's basically how compiler writers treat undefined behavior - just assume it doesn't happen. Yes, but this phrase is ambiguous. What it is meant to refer to is "ignoring the situation completely with unpredictable results," i.e., ignore that writing to that random address is theoretically unpredictable, and just do it, consequences be damned. What compiler writers sometimes actually do is prove by static analysis that the pointer was freed, or never initialized, and then predicated on that situation, rather than ignoring that situation, generate machine code that elides it entirely. Since they know the code is undefined behavior, and they "assume UB doesn't exist," they assume the code cannot execute. When strlen() keeps iterating through memory, the behavior is closer to the former than the latter.

trealira 2y ago
What they do is make assumptions like "null pointers are never dereferenced." So, they write optimizations that assume it doesn't happen. When their UB-oblivious optimizer runs into a situation where the user dereferences a pointer, then checks for null later, it basically reasons "The pointer was dereferenced earlier, so this pointer is definitely not null," implicitly assuming that null pointers are never dereferenced. "Therefore, this null check is unnecessary and can be deleted." This is simplified somewhat, since there are now flags to warn on potential null dereferences and to never delete any null pointer checks. It sounds malicious, but it's simply oblivious. The same mechanism would delete null pointer checks in cases like these: while (p && p->data != NUMBER) { ... if (p && p->data < NUMBER) { ... } ... } To enter the loop, the pointer can't be null, so that check can be rewritten to this: if (p->data < NUMBER) { ... } And it works for other things, too. while (a && b && c) if (a) { ... } else if (b) { ... } else if (c) { ... } Because the only way to enter the loop is for a and b and c to be true, that can be rewritten to the equivalent of this to remove unnecessary double checks: for (;;) { if (a) { ... } else if (b) { ... } else if (c) ... } else break; } Edit: Except, it doesn't rewrite source code. By the time it makes these optimizations, it's working with control flow graph in SSA form. These are all optimizations made after tons of passes, and it's harder to guess what the programmer intended. Some undefined behavior may be introduced by one pass and then gone after the next. That's why there are both warnings about null pointer dereferences, and then it goes on to apply aggressive optimizations based on those null pointer dereferences anyway. The left hand doesn't know what the right hand is doing.

trealira 2y ago

What they do is make assumptions like "null pointers are never dereferenced." So, they write optimizations that assume it doesn't happen. When their UB-oblivious optimizer runs into a situation where the user dereferences a pointer, then checks for null later, it basically reasons "The pointer was dereferenced earlier, so this pointer is definitely not null," implicitly assuming that null pointers are never dereferenced. "Therefore, this null check is unnecessary and can be deleted." This is simplified somewhat, since there are now flags to warn on potential null dereferences and to never delete any null pointer checks. It sounds malicious, but it's simply oblivious. The same mechanism would delete null pointer checks in cases like these: while (p && p->data != NUMBER) { ... if (p && p->data < NUMBER) { ... } ... } To enter the loop, the pointer can't be null, so that check can be rewritten to this: if (p->data < NUMBER) { ... } And it works for other things, too. while (a && b && c) if (a) { ... } else if (b) { ... } else if (c) { ... } Because the only way to enter the loop is for a and b and c to be true, that can be rewritten to the equivalent of this to remove unnecessary double checks: for (;;) { if (a) { ... } else if (b) { ... } else if (c) ... } else break; } Edit: Except, it doesn't rewrite source code. By the time it makes these optimizations, it's working with control flow graph in SSA form. These are all optimizations made after tons of passes, and it's harder to guess what the programmer intended. Some undefined behavior may be introduced by one pass and then gone after the next. That's why there are both warnings about null pointer dereferences, and then it goes on to apply aggressive optimizations based on those null pointer dereferences anyway. The left hand doesn't know what the right hand is doing.