FFI section suggests dangerous practice of using empty opaque type

[RalfJung]

The FFI section of the Nomicon currently suggests to use an empty type for "opaque pointer types". That seems pretty dangerous. This came up in the discussion at rust-lang/rfcs#1861, and also in https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602 many were not happy with using the empty type here.

Until we have proper opaque types, the safer suggestion seems to be do use a ZST with a private field, rather than an empty type. Then at least the type is not actively lying.

[sfackler]

How is this dangerous?

[RalfJung]

with x: &Empty, match *x {} could well be (no final decision has been bade yet) insta-UB if ever executed.

Actually, just passing a &Empty to another function is not really different from passing aliasing &mut u32 -- the promise made by the type is violated. It is not unlikely for the unsafe code guidelines process to decide that doing either of these is UB.

[sfackler]

&Empty is not okay, but you're working with *mut Empty and *const Empty in FFI.

[RalfJung]

&Empty is not okay,

Glad we agree on that. :)

you're working with *mut Empty and *const Empty in FFI.

While these types are fine, I am worried that people will quickly move to variables or function arguments of type &Empty in the wrappers they build around their FFI code.

This happened e.g. in https://github.com/briansmith/ring/, where BIGNUM used to be an empty enum, and you can indeed find &BIGNUM in the code.

[SimonSapin]

I’ve opened #44 to recommend zero-size structs with a private field, instead.

rust-lang/rust#45225 (comment) is another case of Bad Things happening with empty enums used in types that are not "impossible".