News for hackers. Stuff that matters.
Re:“What the Hardware Does” Is Not What Your Program Does: U... by comex on Monday July 15, 2019 @03:20AM (#20438786)
> "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.

Re:“What the Hardware Does” Is Not What Your Program Does: U... by littlestymaar on Monday July 15, 2019 @06:22AM (#20439437)
> 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.

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Monday July 15, 2019 @07:38AM (#20439833)
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.

Re:“What the Hardware Does” Is Not What Your Program Does: U... by robocat on Monday July 15, 2019 @05:28AM (#20439238)
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).
Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Monday July 15, 2019 @07:41AM (#20439855)
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`?

Re:“What the Hardware Does” Is Not What Your Program Does: U... by robocat on Monday July 15, 2019 @03:52PM (#20444517)
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

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Tuesday July 16, 2019 @08:23AM (#20449362)
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.