“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 martinhath on Monday July 15, 2019 @07:45AM (#20439881)

I _think_ I understand the rationale behind `undef` in LLVM, but I still think it's a bad one, since it can, and does, lead to very surprising behaviour.

> LLVM propagates the `undef` outward through the expression until the whole condition is `undef`, and then it arbitrarily picks that the condition should be false.

I think this illustrates what I find counter-intuitive about this whole mess; any function of `undef` shouldn't itself be `undef`. `undef < undef` is false in my head. `undef < 150` is just unknown, not undefined, since we don't know what `undef` is.

> Basically, it helps to be able to replace "cond ? some_value : undef" with "some_value"

This feels really contrived; in what setting would this actually be useful?

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by comex on Monday July 15, 2019 @03:45PM (#20444456)

> This feels really contrived; in what setting would this actually be useful?

The text file I linked to explains it in more detail, so I'll defer to that.

> I think this illustrates what I find counter-intuitive about this whole mess; any function of `undef` shouldn't itself be `undef`. `undef < undef` is false in my head. `undef < 150` is just unknown, not undefined, since we don't know what `undef` is.

Except that for `undef < undef`, what if they're two different undefs? You would have to track each potentially uninitialized value separately. And then the optimizer would want to strategically choose values for the different undefs – e.g. "we want to merge 'cond ? some_value : undef123' with 'some_value', so let's set undef123 equal to some_value... except that could negatively impact this other section of code that uses it". It's certainly possible, but it would make the optimizer's job somewhat harder.

[ Parent | on HN ]