Reference to uninitialized memory is not caught

[nandesu-utils]

An intermediary reference to uninitialized memory is not caught up. It is produced when taking that reference and then converting it to a pointer.

Rust playground permalink: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=811c791ba18d604f1553f1b2dd27108e

[bjorn3]

When checking validity for references, the referenced memory is not checked for validity. This is by design I believe, but I can't quite explain why.

[nandesu-utils]

When checking validity for references, the referenced memory is not checked for validity. This is by design I believe, but I can't quite explain why.

Is it miri's design or Rust's one?

As it states here:

Producing an invalid value, even in private fields and locals. "Producing" a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation. The following values are invalid (at their respective type):
...

• A reference or Box that is dangling, unaligned, or points to an invalid value.

And also:

Uninitialized memory is also implicitly invalid for any type that has a restricted set of valid values.

As I understand creating a reference means producing it, and it is invalid because it is a reference that points to an invalid value which is uninitialized memory.

[5225225]

We're not sure if this is UB or not (see: rust-lang/unsafe-code-guidelines#77).

But it probably won't be UB because it's difficult to check this (Every time you move a &[u8; 1_000_000], you have to check the whole of the array there Just In Case any of it has been invalidated)

Not to mention recursive types. These aren't impossible problems, but it would make the job of miri harder.

[saethlin]

I do not think the performance arguments are compelling. I might be convinced, if someone would implement validity-behind-references, then give me time to try to make it faster.

But in any case, I think the much bigger concern is how surprising this would be for unsafe programmers, and how much existing code it would make invalid. Basically: rust-lang/unsafe-code-guidelines#346

[RalfJung]

This is indeed a deliberate difference between Miri and the Reference, and documented prominently in the README:

There are still plenty of open questions around the basic invariants for some types and when these invariants even have to hold. Miri tries to avoid false positives here, so if your program runs fine in Miri right now that is by no means a guarantee that it is UB-free when these questions get answered.

In particular, Miri does currently not check that references point to valid data.

A final decision for Rust semantics has not been made, so the reference is conservative and says this is forbidden. Miri does not guarantee to detect all UB and hence, for now, does not do these checks. I also hope we will officially allow such references to invalid data in the future; most people seem to be in favor of that. If someone wanted to implement them we could add an opt-in flag for these checks.

However, notice that references to uninhabited types are considered UB even by Miri, as this example shows.

[RalfJung]

I am going to close this, since Miri behaves as intended and as documented. Feel free to ask any further questions that you have, though!