4 ms·

That article agrees with me, not you. Even in the time travel examples, the code paths unrelated to the ub can't be touched. In other words, it can travel back

That article agrees with me, not you. Even in the time travel examples, the code paths unrelated to the ub can't be touched. In other words, it can travel backward, but not sideways (which is what you originally claimed).

lisper 9y ago
> Even in the time travel examples, the code paths unrelated to the ub can't be touched. Of course they can. UB licenses the program to do anything including re-write any part of itself.
- jjnoakes 9y ago
  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.
  - lisper 9y ago
    > 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.
    - jjnoakes 9y ago
      > Not for all inputs 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.
      - lisper 9y ago
        > Not in my example there isn't. 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.
        jjnoakes 9y ago
        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.

lisper 9y ago

> Even in the time travel examples, the code paths unrelated to the ub can't be touched. Of course they can. UB licenses the program to do anything including re-write any part of itself.

jjnoakes 9y ago
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.
- lisper 9y ago
  > 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.
  - jjnoakes 9y ago
    > Not for all inputs 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.
    - lisper 9y ago
      > Not in my example there isn't. 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.
      - jjnoakes 9y ago
        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.