> This is only true if the undefined behavior is guaranteed to be reachable.
Nope. It's true if the UB is possibly reachable.
See: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=...
Nope. It's true if the UB is possibly reachable.
See: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=...
In other words, it can travel backward, but not sideways (which is what you originally claimed).
Of course they can. UB licenses the program to do anything including re-write any part of itself.
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);
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);
}
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.
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.
Want to bet? How much are you willing to wager? (And yes, I accept all the conditions you listed.)
> The problem is that you don't really understand UB fully
Then this is a chance for you to make some easy money.
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.
Only if it is reachable under the given inputs. We've gone over this, and you were on the right track a few comments up. Why revert now?
> Writing a non-trivial C program that contain no UB is practically impossible > The point is that you think you can write correct C code
We happen to agree on both of these points, but I'm not sure how you got on this topic? Let's stay focused...
> And no, I'm not going to tell you what it is because that would be missing the point.
That's about what I expected, since there's no UB in my example.
Good day!
Yes, I already conceded that.
> there's no UB in my example
Then here is an opportunity for you to show me up and make some easy money. How much are you willing to bet?
The ball's in your court man. Posturing around a wager is just you flailing around, empty handed.
https://spin.atomicobject.com/2014/05/19/c-undefined-behavio...
but I just noticed that you actually specified your ints to be unsigned. So I would have lost. (And I would have paid.)
I almost missed this one! Here's some choice quotes for you:
From https://news.ycombinator.com/item?id=16917162
> "Undefined behavior anywhere in the program can legally make any part of the program do anything at any time."
and from https://news.ycombinator.com/item?id=16917551
> "It's true if the UB is possibly reachable."