> "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.

> Technically he should have said "less than or equal to 120" rather than just "less than", but otherwise it's accurate.

I suspect it may be because the author is German. In French at least «inférieur» means “less or equal than” and you need to say «strictement inférieur» to say “less than”, and I wouldn't be surprised if it were the same in German.

That and it is really tedious to spell out "less than or equal to", in German we have a much shorter phrase for it ("kleiner-gleich").

But thanks for pointing out this mistake, I will fix it immediately.

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).

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`?

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 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/unde... and https://lkml.org/lkml/2018/6/5/769

The argument for C not being low-level is not via UB, it is via the fact that a lot happens when C gets translated to assembly, and to explain that you need to consider an abstract machine that is many things, but not low-level.

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

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.

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). :)

I talked a bit about it here: 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.

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