UB only licenses the program to do anything if it is reachable. Unreachable, unexecuted, cant-be-executed UB simply can't change a program's behavior. I'm not sure why you think it can.
Do you think this program can "do anything" or "re-write any part of itself"?
unsigned int x = <input from user>;
unsigned int y = <input from user>;
printf("%u\n", x / y);
The compiler must output valid code for that program, and execution (not compilation) can only "do anything" if the user enters values that invoke UB (like "y == 0" for example). For all valid inputs this program must execute correctly and can not "do anything", even at runtime, do you agree?
What about this one?
unsigned int x = <input from user>;
unsigned int y = <input from user>;
if (y == 0) {
printf("%u\n", x / y);
} else {
printf("%u\n", x * y);
}
Same idea: this program can only "do anything" if the user enters "y == 0". The compiler can see that "x / y" would invoke UB, and remove the entire "if (y == 0) { ... }" branch (because the compiler can assume it is never reached, otherwise it would invoke UB), but the compiler can not do anything to change the behavior of the "else" branch - entering any non-zero "y" value must produce correct output, so the program can't just be compiled to "do anything".
Only the paths related to the UB can be optimized/modified/rewritten by the compiler based on that UB, and if those optimizations or modifications affect the proper execution of paths unrelated to the UB (i.e. paths where the UB can not be reached from), then the optimization or modification in question is a compiler bug.
> UB only licenses the program to do anything if it is reachable.
That's true, but it doesn't help much.
> Do you think this program can "do anything" or "re-write any part of itself"?
Yes. Not for all inputs, but yes.
> this program can only "do anything" if the user enters "y == 0".
Nope. There is at least one other input value that produces UB.
And this is exactly the problem: even on a trivial example that you contrived, you cannot fully enumerate all the circumstances that produce UB. For real programs, the situation is hopeless.
Which proves my point: a program can't "do anything" just because some part of it may contain UB. Only the UB paths are allowed to "do anything".
> There is at least one other input value that produces UB.
Not in my example there isn't (assuming proper context for the example code, i.e. you aren't doing "#define printf (something evil)", you include the right headers, you define main properly, etc, etc).
> And this is exactly the problem: even on a trivial example that you contrived, you cannot fully enumerate all the circumstances that produce UB
The problem is that you don't really understand UB fully and are making incorrect claims about it repeatedly.
I'm not claiming UB can't cause problems, but it doesn't cause problems in some of the ways you've been quite vocal about.
No wager necessary, feel free to point out my mistake, if I made one. It won't prove that you know what you are talking about in general (since, as we've seen, programs really can't "do anything" if they have UB anywhere in them), but I do like to know when I make mistakes, and I'll fully own up to it if I did.
> programs really can't "do anything" if they have UB anywhere in them
I never said they could.
> I do like to know when I make mistakes
I doubt that very much, but let's do the experiment:
Here is one of your many mistakes:
"Even in the time travel examples, the code paths unrelated to the ub can't be touched."
That's simply not true. UB licenses a program to do anything, including overwriting itself. Which means that the compiler can anticipate this and emit arbitrary code.
Now, you might, if you are very very careful, be able to construct a program that contains UB that is guaranteed to behave as intended for some non-zero time interval. You might even be able to construct a program that contains no UB at all, though this is even more challenging. Writing a non-trivial C program that contain no UB is practically impossible. I doubt there is even a single such program in existence in the world today. Your trivial examples both contain UB. And no, I'm not going to tell you what it is because that would be missing the point. The point is not that I know some detail of the C standard that you have overlooked (though that is in fact true). The point is that you think you can write correct C code, and you can't. No one can.
> I'll fully own up to it if I did.
I doubt that very much too, but I'm ready to be surprised.
I would wager quite a bit (I wager my career on things like this daily), but based on the ability for you to communicate effectively and based on facts thus far, I'm not entirely convinced that when you end up being wrong, you'd accept it, understand it, and pay up.
The ball's in your court man. Posturing around a wager is just you flailing around, empty handed.
Yeah, yeah, there is a special case that if the UB is not reachable then it's a no-op. That doesn't change the fact that writing correct non-trivial C code is practically impossible.
Nope. It's true if the UB is possibly reachable.
See: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=...