4 ms·

Do we really need such an obscure metaphor? Why not talk about how the compiler reacts to undefined behavior in real concrete terms?

sfink 3y ago
I will probably say something stupid and subtly wrong here, but my understanding is that the only concrete thing that you can say about the compiler's reaction is that it will assume that whatever would trigger the UB will never happen. Equivalently, that it is impossible to exhibit undefined behavior, and what code gets executed to perform that behavior is irrelevant because it'll never happen. What this means in practice is not concrete at all, or rather it is only meaningful in relation to a rather large set of things: the compiler, its version, the optimizations enabled and applicable, the platform, etc. The optimizations applicable are dependent in your program too, so even though the ramifications are usually (but not always) deterministic, even that may not help. You might add one more call, now something is inlined that wasn't before, and because you compute `i+5` 300 lines later, the compiler can assume `i <= MAX_INT - 5` in the body of the now-inlined function and so it can now just drop a comparison you were making to prevent overflow since it knows the later overflow Can Never Happen so there's no point emitting code that will never execute.
- wyldfire 3y ago
  > the only concrete thing that you can say about the compiler's reaction is that it will assume that whatever would trigger the UB will never happen Yeah! isn't that enough? Your program is Wrong and therefore it should be fixed. Reasoning about the wrongness is not time well spent. Just consider it a defect and mitigate it.
  - sfink 3y ago
    I'm not sure what you're recommending here. There are many, many ways to trigger undefined behavior. The compiler won't tell you when you might be. Well, unless you're using a sanitizer like ubsan, but even then it'll only tell you about some. So I'm not sure when I should go fix my program that I don't know needs to be fixed. Yes, in theory you could internalize all of the rules and write UB-free code. While you're at it, be sure you only write code with no bugs at all. I'm not sure why everyone isn't doing that already...

sfink 3y ago

I will probably say something stupid and subtly wrong here, but my understanding is that the only concrete thing that you can say about the compiler's reaction is that it will assume that whatever would trigger the UB will never happen. Equivalently, that it is impossible to exhibit undefined behavior, and what code gets executed to perform that behavior is irrelevant because it'll never happen. What this means in practice is not concrete at all, or rather it is only meaningful in relation to a rather large set of things: the compiler, its version, the optimizations enabled and applicable, the platform, etc. The optimizations applicable are dependent in your program too, so even though the ramifications are usually (but not always) deterministic, even that may not help. You might add one more call, now something is inlined that wasn't before, and because you compute `i+5` 300 lines later, the compiler can assume `i <= MAX_INT - 5` in the body of the now-inlined function and so it can now just drop a comparison you were making to prevent overflow since it knows the later overflow Can Never Happen so there's no point emitting code that will never execute.

wyldfire 3y ago
> the only concrete thing that you can say about the compiler's reaction is that it will assume that whatever would trigger the UB will never happen Yeah! isn't that enough? Your program is Wrong and therefore it should be fixed. Reasoning about the wrongness is not time well spent. Just consider it a defect and mitigate it.
- sfink 3y ago
  I'm not sure what you're recommending here. There are many, many ways to trigger undefined behavior. The compiler won't tell you when you might be. Well, unless you're using a sanitizer like ubsan, but even then it'll only tell you about some. So I'm not sure when I should go fix my program that I don't know needs to be fixed. Yes, in theory you could internalize all of the rules and write UB-free code. While you're at it, be sure you only write code with no bugs at all. I'm not sure why everyone isn't doing that already...