Matching on uninhabited unsafe places (union fields, raw pointer dereferences, etc.) allowed in safe code.

[nagisa]

With the following code

fn main() {
    #[derive(Copy, Clone)]
    enum Void {}
    union A { a: (), v: Void }
    let a = A { a: () };
    match a.v {
    }
}

it is possible to invoke undefined behaviour in safe code without using unstable features.

[nikomatsakis]

Seems like unions elements ought to be inhabited.

cc @petrochenkov @joshtriplett

[nikomatsakis]

@nagisa points out that we can't tell if generic types are inhabited, so maybe such a fix is not viable.

[nikomatsakis]

cc @rust-lang/lang -- a bit of a tricky thing to decide what we should disallow here, though I'm leaning towards "safe access to union fields", or at least restricting the cases further (e.g., to those cases where know more than copy, but also inhabited)

[nikomatsakis]

Also: @eternaleye points out uninitialized values (e.g., on itanium) may trap if you read from them, and this union RFC would seem to allow access to them from safe code. Leaning more and more towards "union fields should never be safe to access". =)

[eddyb]

When did the decision for safe accesses to union fields happen? I do not recall any such proposal or discussion and I would think that I had to sign off on it.
EDIT: turns out "safe copy out of union fields" doesn't seem to exist, see #47412 (comment).

We've known for a long time that a bitcast between two types (with the same number of bits) is safe iff all possible bitpatterns of each of the two types are valid and they correspond to distinct values.
(Note that reading uninitialized memory, including inter-field padding, is unsafe in Rust)
Sometimes this was called "POD" (but it's much stricter than the C/C++ concept with the same name).

[joshtriplett]

Is this actually UB, and should it be? enum Void should have size zero, and "accessing" it should not actually do a memory read, nor should that match generate any code.

EDIT: Ah, nevermind, I understand.

I tried this on the playground, and the entire function compiles down to a single undefined instruction (ud2); in LLVM, it compiles to an unreachable.

Also, I don't recall us ever making union field reads safe. Does this somehow work outside an unsafe block because the match doesn't actually do any pattern-matching? It seems like the reference to a.v alone should have required an unsafe block.

(Also, good catch, @nagisa!)

[eternaleye]

@joshtriplett: It's not that "accessing" it is UB; it's that accessing it produces a value whose mere existence is UB, because enum Void {} has no values.

[joshtriplett]

@eternaleye Thanks; yeah, took staring at it for a while to realize that was the problem here.

[eternaleye]

Note that you can also get UB with

fn main() {
    union A { a: u8, v: u16 }
    let a = A { a: 1 };
    match a.v {
        _ => println!("Congrats, it's a u16!")
    }
}

as this reads one of the u16's bytes from uninitialized memory.

[joshtriplett]

@eternaleye That code won't compile; it'll generate error[E0133]: access to union field requires unsafe function or block. (Among a couple of other things.) Try it in the playground.

After experimenting with this a fair bit, it looks like match a.v isn't actually treated as something that requires an unsafe block itself, only the pattern within the match. Can we fix that? The original union RFC says that matching on a union field requires an unsafe block; I think that should be the case even without patterns, or with the only pattern as _. Wouldn't that fix this issue?

Attempting to compile @nagisa's original example should produce the same error E0133 at compile time.