4 ms·

The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that th

The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. Writing through an invalid pointer is perfectly definable. The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted, but that whether the write succeeds and what second- and third-order effects result from such a write are dependent on the environment, including operating system. Boom. Not undefined behavior. But still potentially dangerous behavior with unpredictable results. (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.)

UncleMeat 2y ago
> The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted It could. But now you can't optimize things to store data in registers hardly ever.
trealira 2y ago
> (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.) By not imposing any requirements for undefined behavior, ISO C does not require that, but maybe it ought to. > Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. > But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. The latter is a consequence of the former. Compiler writers treat undefined behavior as though it can't happen, and this causes unpredictable behavior. Suppose you had code like this in C: #define Variant1 0 #define Variant2 1 void use_variant(int variant) { if (variant == 0) { // Variant1 } else { // Must be Variant2 } } You are assuming your code is always passed a 1 or a 0, not checking for any other possibilities, which is basically treating other possibilities as "can't happen". Code that passes it a 2 might get one kind of behavior now, and another kind of behavior later, when the function updates. Your function may have wildly inconsistent behavior on different versions of the same function when given inputs of 2 because you're treating that as undefined behavior. That's basically how compiler writers treat undefined behavior - just assume it doesn't happen. And, that's how standard C library functions work. Functions like strlen assume you never give it a null pointer; they will just dereference pointers unconditionally.
- torstenvl 2y ago
  > 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.

UncleMeat 2y ago

> The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted It could. But now you can't optimize things to store data in registers hardly ever.

trealira 2y ago

> (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.) By not imposing any requirements for undefined behavior, ISO C does not require that, but maybe it ought to. > Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. > But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. The latter is a consequence of the former. Compiler writers treat undefined behavior as though it can't happen, and this causes unpredictable behavior. Suppose you had code like this in C: #define Variant1 0 #define Variant2 1 void use_variant(int variant) { if (variant == 0) { // Variant1 } else { // Must be Variant2 } } You are assuming your code is always passed a 1 or a 0, not checking for any other possibilities, which is basically treating other possibilities as "can't happen". Code that passes it a 2 might get one kind of behavior now, and another kind of behavior later, when the function updates. Your function may have wildly inconsistent behavior on different versions of the same function when given inputs of 2 because you're treating that as undefined behavior. That's basically how compiler writers treat undefined behavior - just assume it doesn't happen. And, that's how standard C library functions work. Functions like strlen assume you never give it a null pointer; they will just dereference pointers unconditionally.

torstenvl 2y ago
> 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.