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.