Comment by timtadh | Hacker News Reader

Comment by timtadh | Hacker News Reader

Parent Full thread

Question 2 is :

Is reading an uninitialised variable or struct member (with a current mainstream compiler):

(This might either be due to a bug or be intentional, e.g. when copying a partially initialised struct, or to output, hash, or set some bits of a value that may have been partially initialised.)

a) undefined behaviour (meaning that the compiler is free to arbitrarily miscompile the program, with or without a warning) : 128 (43%)

b) ( * ) going to make the result of any expression involving that value unpredictable : 41 (13%)

c) ( * ) going to give an arbitrary and unstable value (maybe with a different value if you read again) : 20 ( 6%)

d) ( * ) going to give an arbitrary but stable value (with the same value if you read again) : 102 (34%)

e) don't know : 3 ( 1%)

f) I don't know what the question is asking : 2 ( 0%)

--------------------

I know of one datastructure (a sparse set of integers from 1-n) which relies on this behavior: http://research.swtch.com/sparse . I always thought it was a neat trick. However, from the article is seems that may NOT give stable values to uninitialized members. Which may make that data structure behave strangly or cause the program to miscompile.

Generally speaking, it depends on where the uninitialized value is located (Though, AFAIK, by the standard they are all to be considered unstable for the most part). The big catch is stack-allocated uninitialized variables. What gcc may do (and I presume clang/LLVM too) is assign an uninitialized variable to a register, but then never give it any stack-space. So, what happens is that the code my always treat register 'a' as though it contains variable 'i', but since variable 'i' is uninitialized, it never allocates or reads anything from the stack, so the value of 'i' just becomes whatever happens to be inside of register 'a' before you attempted to use it. This would cause the variable to appear to randomly change from one value to another, even during single statements, depending on what register 'a' get's used for.

For the sparse set of integers, generally speaking that's going to be allocated somewhere else all at once, so there is not much the compiler can do to 'realize' it's uninitialized and decide to just ignore the read from memory completely. A fancy compiler could presumably flag every uninitialized location, then do checks and use some random value every-time you attempt to use one, but practically speaking no compiler is going to do that, so this data-structure isn't technically standards compliant, but it should probably still work anyway.

That's a question for which multiple answers are correct: a, b, and c.

I disagree regarding b. I think you'll find the outcome of this expression quite predictable:

int b; int c = b * 0;

Sure, if the expression doesn't depend on the value at all, it probably won't have unpredictable results. (Though as with any kind of undefined behavior, don't count on it, as compilers can be "clever" sometimes.)

Reply on news.ycombinator.com