“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Monday July 15, 2019 @07:22AM (#20439728)

> The assembly has to enforce the abstract machine.

The assembly has to implement the abstract machine only if your program has no UB. The assembly never has to check if memory is "initialized" or not even though that distinction is real on the abstract machine, because if the difference would matter, your program would have UB.

To determine if your program has UB, looking at the assembly is useless. The only way is to consider the abstract machine.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @11:24AM (#20441666)

Personally, I like to bind the compiler to implementing the abstract machine in all cases, and in the face of undefined behavior the abstract machine has no requirements on its behavior. Of course, this is just a semantic quibble: in practice, the results are the same ;)

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by archgoon on Monday July 15, 2019 @11:22AM (#20441652)

When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Tuesday July 16, 2019 @08:19AM (#20449340)

The standard will not specify anything, so what the compiler outputs is gibberish. You are literally looking at a sequence of bytes on which no constraints whatsoever are imposed. LLVM could have compiled my UB program do `0xDEADBEEF` (which I assume is not valid x86 but I do not know) and there would be no compiler bug. Looking at `0xDEADBEEF` here is not useful.

Trying to interpret the assembly of a UB program is like trying to interpret the noise of a radio when there is no station on the given frequency. It has more to do with fortune telling than anything else. There is no signal in there, or at least not enough of it to be useful.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @11:25AM (#20441683)

No, because the compiler will not generate code that is consistent in this case.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by archgoon on Monday July 15, 2019 @11:26AM (#20441696)

So? What do you think I'm arguing for here?

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @11:44AM (#20441905)

There is no standard mapping between "your C code" and "what your computer will do" if your code has undefined behavior. Your compiler will produce some assembly, which you cannot rely on, and that will be "what your hardware does". If that's what you're trying to say I think we agree.

[ Parent | on HN ]