3 ms·

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,

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.
- jjnoakes 9y ago
  > I never said they could. I almost missed this one! Here's some choice quotes for you: From https://news.ycombinator.com/item?id=16917162 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 https://news.ycombinator.com/item?id=16917551 > "It's true if the UB is possibly reachable."
  - lisper 9y ago
    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.
    - jjnoakes 9y ago
      No argument here, I'm just trying to keep the facts straight; I have no opinion on right/wrong/good/bad/easy/hard (at least, not in this forum).

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.
jjnoakes 9y ago
> I never said they could. I almost missed this one! Here's some choice quotes for you: From https://news.ycombinator.com/item?id=16917162 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 https://news.ycombinator.com/item?id=16917551 > "It's true if the UB is possibly reachable."
- lisper 9y ago
  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.
  - jjnoakes 9y ago
    No argument here, I'm just trying to keep the facts straight; I have no opinion on right/wrong/good/bad/easy/hard (at least, not in this forum).