5 ms·

> 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 any

> 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
    > 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.
    - jjnoakes 9y ago
      > UB licenses a program to do anything 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!
      - lisper 9y ago
        > Only if it is reachable under the given inputs 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?
        jjnoakes 9y ago
        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.
        lisper 9y ago
        Well, you would have won. I was thinking of this: https://spin.atomicobject.com/2014/05/19/c-undefined-behaviors/ 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.)
        jjnoakes 9y ago
        Thanks for coming clean.

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
  > 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.
  - jjnoakes 9y ago
    > UB licenses a program to do anything 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!
    - lisper 9y ago
      > Only if it is reachable under the given inputs 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?
      - jjnoakes 9y ago
        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.
        lisper 9y ago
        Well, you would have won. I was thinking of this: https://spin.atomicobject.com/2014/05/19/c-undefined-behaviors/ 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.)
        jjnoakes 9y ago
        Thanks for coming clean.