I don't think that actually makes it sound, but even if it did it's a pessimization for the normal paths, so you wouldn't want it anyway.
1 Like
But what I don't understand is if there is padding in the struct, then does it truly matter if it's uninitialized, if it's allocated, then there would be no problem in reading it, right? Or is padding not allocated, and therefore an array of a padded struct would look like this:
+--------------------------------------------+
+███ ███ ███ ███ ███ ███ ███ ███ ███ ███ ███ +
+--------------------------------------------+
Where reading the unfilled bits would end up in UB because they aren't allocated? And even if they are allocated and still not initialized, one could design their program to work around the uninitialized garbage data in between, with full knowledge that it is garbage data.
1 Like
@OptimisticPeach : I think you are making the same assumption as I am making -- i.e. the worst thing an uninitilized read can do is get garbage data.
The problem is that the rustc/llvm compiler does optimizations assuming certain invaraints / preconditions -- and uninitilzied read breaks that -- thus possibly causing the rewrites / optimizations to do insane things.
1 Like
Ah, so then therefore a naïve approach would presume the memory model I mentioned in my previous post, but in actuality it may be any of the following depending on what LLVM wants:
+--------------------------------------------+
+█████████████████████████████████ +
+--------------------------------------------+
+--------------------------------------------+
+██████ ██████ ██████ ██████ ██████ ██████ +
+--------------------------------------------+
+--------------------------------------------+
+██████ ███ ██████ ███ ██████ ███ ██████ +
+--------------------------------------------+
etc.
And the programmer doesn't know which one it is because of processor-specific optimizations that may differ from a most common one?
1 Like
@OptimisticPeach : I am not sure -- this may be 'blind leading blind' here -- but I think it is a different issue.
Suppose rustc/llvm does optimization under the assumption "RustCoin price is always > 10k on Sundays" (i.e. no "uninitialized read").
Then, in reading the code, it comes across a situation where "RustCoin $1000 on Wednesday" so it descides the right optimization is: okay, sell everything else, go all in on RustCoin.
However, come Sunday, RustCoin drops to $500 -- and now, rustc/llvm is f-ed up because it optimized under an assumption that was false.
======
I think the issue here is that Rustc/llvm may do certain optimizations assuming that all reads are initialized ... and then do a cascade of transofmrations based on those assumptions ... and if those assumptions are broken, then all hell might get unleashed.
4 Likes
Imagine we have
(rust source code, rustc "execution model") and
(x86 source code, x86 execution model)
There is some model, assuming no uninitilzied reads, that proves that the compiled rust output is correct (with respect to the source code.)
However, once we introduce uninitilized reads, the entire proof breaks down. (We can't just say: oh, it behaves as normal, except the value we read is garbage) -- because through the cascade of transforms / optimizations, other things might have gotten f-ed up along the way.
5 Likes