5 ms·

There's a link to the generated machine code in a footnote (for a variant returning a bool rather than calling assert!). It's literally just xor eax, eax

There's a link to the generated machine code in a footnote (for a variant returning a bool rather than calling assert!). It's literally just xor eax, eax ret

robocat 7y ago
That's what I expected. And I that is probably due to an optimisation rather than uninitialised variables (can anyone confirm that?). I am sceptical the author really knows much as some of their statements seem blatantly wrong or just nonsense: "So, one time we 'look' at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change." Is talking about "x < 150 || x > 120", but gets it the wrong way around, ouch! "Memory remembers if you initialized it. The x that is passed to always_return_true is not the 8-bit representation of some number, it is an uninitialized byte." Benefit of doubt could be extremely poor metaphors, or referencing the wrong code? Also stating C is not low-level is a conceited attempt to redefine the word.
- Dylan16807 7y ago
  > Also stating C is not low-level is a conceited attempt to redefine the word. I expect a low level language to run the code I typed, or something that has the same effect. They're not redefining the term. C itself has been redefined away from its origins.
- saagarjha 7y ago
  The author tries to ascribe too much meaning to undefined behavior and gets some parts of this wrong, but they are correct in saying that C is not a low-level language in the context that they're using it.
  - ralfjung 7y ago
    I don't think I got any of it wrong, but in case I did I'd appreciate if you could point out my mistake(s). :)
    - saagarjha 7y ago
      I talked a bit about it here: https://news.ycombinator.com/item?id=20435309 https://news.ycombinator.com/item?id=20435309. Basically, the compiler has no need to do things like perform reads in the face of undefined behavior: it could output an empty executable if it wished. Maybe your specific version of the compiler does, but that doesn't mean others (or even a future version of yours) will. Trying to figure out what a compiler might do in the face of undefined behavior is generally not a worthwhile exercise.
      - ralfjung 7y ago
        > Trying to figure out what a compiler might do in the face of undefined behavior is generally not a worthwhile exercise. That is exactly the point of my post! If you think I disagree with that statement, we seriously miscommunicated somewhere. The parts you seem to be concerned about are those where I try to explain why the abstract machine is the way it is. Hardware and compiler concerns do come in at that point, and my feeling is just dogmatically giving an abstract machine won't help convince people of its usefulness.
- comex 7y ago
  > "So, one time we 'look' at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change." > Is talking about "x < 150 || x > 120", but gets it the wrong way around, ouch! It's not the wrong way around. The assertion failure being discussed happens when the function returns false, which happens when both sides of the || are false. Technically he should have said "less than or equal to 120" rather than just "less than", but otherwise it's accurate.
  - robocat 7y ago
    Fair call. But the real point is that the function gets compiled to: xor eax, eax ret i.e. the input variable is not compared with 150 or 120. His intuition about his code is wrong - it has been compiled out (unless I am missing something about choosing a different optimisation level, or declaring things volatile, etc).
    - ralfjung 7y ago
      You are making exactly the mistake the post is all about. :) Only UB-free programs can be made sense of by looking at their assembly. Whether a program has UB is impossible to tell on that level. For that, you need to think in terms of the abstract machine. I mean, look at the code I wrote! It literally compares `x` with 150 and 120. That's the program I wrote. This program has a "meaning"/"behavior" that is entirely irrelevant of compilers and optimizations, and determined by the langauge specification. How can you argue that it does compare `x`?
      - robocat 7y ago
        Right. When you are talking about the compiler and the abstract machine, perhaps some sentences could be clearer about that (e.g. the sentences I latched onto - which I admit is my fault for skim reading). Responding to whether C is "low-level" I like this comment: http://lambda-the-ultimate.org/node/5534#comment-95721 http://lambda-the-ultimate.org/node/5534#comment-95721 And processors have undefined behaviour so should we say assembly is not "low-level"? e.g. "Grep through the ARM architecture reference manual for 'UNPREDICTABLE' (helpfully typeset in all caps), for example…" - pcwalton Thanks heaps for your article which was a good read, and it led me to the funnier side of undefined behaviour: https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html#been-there-done-that-got-the-t-shirt https://raphlinus.github.io/programming/rust/2018/08/17/unde... and https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769

There's a link to the generated machine code in a footnote (for a variant returning a bool rather than calling assert!). It's literally just xor eax, eax ret

robocat 7y ago

That's what I expected. And I that is probably due to an optimisation rather than uninitialised variables (can anyone confirm that?). I am sceptical the author really knows much as some of their statements seem blatantly wrong or just nonsense: "So, one time we 'look' at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change." Is talking about "x < 150 || x > 120", but gets it the wrong way around, ouch! "Memory remembers if you initialized it. The x that is passed to always_return_true is not the 8-bit representation of some number, it is an uninitialized byte." Benefit of doubt could be extremely poor metaphors, or referencing the wrong code? Also stating C is not low-level is a conceited attempt to redefine the word.

Dylan16807 7y ago
> Also stating C is not low-level is a conceited attempt to redefine the word. I expect a low level language to run the code I typed, or something that has the same effect. They're not redefining the term. C itself has been redefined away from its origins.
saagarjha 7y ago
The author tries to ascribe too much meaning to undefined behavior and gets some parts of this wrong, but they are correct in saying that C is not a low-level language in the context that they're using it.
- ralfjung 7y ago
  I don't think I got any of it wrong, but in case I did I'd appreciate if you could point out my mistake(s). :)
  - saagarjha 7y ago
    I talked a bit about it here: https://news.ycombinator.com/item?id=20435309 https://news.ycombinator.com/item?id=20435309. Basically, the compiler has no need to do things like perform reads in the face of undefined behavior: it could output an empty executable if it wished. Maybe your specific version of the compiler does, but that doesn't mean others (or even a future version of yours) will. Trying to figure out what a compiler might do in the face of undefined behavior is generally not a worthwhile exercise.
    - ralfjung 7y ago
      > Trying to figure out what a compiler might do in the face of undefined behavior is generally not a worthwhile exercise. That is exactly the point of my post! If you think I disagree with that statement, we seriously miscommunicated somewhere. The parts you seem to be concerned about are those where I try to explain why the abstract machine is the way it is. Hardware and compiler concerns do come in at that point, and my feeling is just dogmatically giving an abstract machine won't help convince people of its usefulness.
comex 7y ago
> "So, one time we 'look' at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change." > Is talking about "x < 150 || x > 120", but gets it the wrong way around, ouch! It's not the wrong way around. The assertion failure being discussed happens when the function returns false, which happens when both sides of the || are false. Technically he should have said "less than or equal to 120" rather than just "less than", but otherwise it's accurate.
- robocat 7y ago
  Fair call. But the real point is that the function gets compiled to: xor eax, eax ret i.e. the input variable is not compared with 150 or 120. His intuition about his code is wrong - it has been compiled out (unless I am missing something about choosing a different optimisation level, or declaring things volatile, etc).
  - ralfjung 7y ago
    You are making exactly the mistake the post is all about. :) Only UB-free programs can be made sense of by looking at their assembly. Whether a program has UB is impossible to tell on that level. For that, you need to think in terms of the abstract machine. I mean, look at the code I wrote! It literally compares `x` with 150 and 120. That's the program I wrote. This program has a "meaning"/"behavior" that is entirely irrelevant of compilers and optimizations, and determined by the langauge specification. How can you argue that it does compare `x`?
    - robocat 7y ago
      Right. When you are talking about the compiler and the abstract machine, perhaps some sentences could be clearer about that (e.g. the sentences I latched onto - which I admit is my fault for skim reading). Responding to whether C is "low-level" I like this comment: http://lambda-the-ultimate.org/node/5534#comment-95721 http://lambda-the-ultimate.org/node/5534#comment-95721 And processors have undefined behaviour so should we say assembly is not "low-level"? e.g. "Grep through the ARM architecture reference manual for 'UNPREDICTABLE' (helpfully typeset in all caps), for example…" - pcwalton Thanks heaps for your article which was a good read, and it led me to the funnier side of undefined behaviour: https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html#been-there-done-that-got-the-t-shirt https://raphlinus.github.io/programming/rust/2018/08/17/unde... and https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769