Skip to content

Commit

Permalink
Rollup merge of rust-lang#56594 - sdroege:c_void-is-not-never, r=TimNN
Browse files Browse the repository at this point in the history
Remove confusing comment about ideally using `!` for `c_void`

Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.

In addition document that newtype wrappers around `c_void` can be used
safely in place of `extern type` until the latter is stabilized.

----

I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all?

Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](rust-lang#43467) stabilization ticket seems relevant

> In [std's](https://github.com/rust-lang/rust/blob/164619a8cfe6d376d25bd3a6a9a5f2856c8de64d/src/libstd/os/raw.rs#L59-L64) source, it is mentioned that LLVM expects i8* for C's void*.
> We'd need to continue to hack this for the two c_voids in std and libc.
> But perhaps this should be done across-the-board for all extern types?
> Somebody should check what Clang does.

Please correct me if my understanding is wrong and everything's actually fine as is.
  • Loading branch information
Centril committed Jan 17, 2019
2 parents 66d859e + 8de8880 commit eb93f41
Showing 1 changed file with 10 additions and 7 deletions.
17 changes: 10 additions & 7 deletions src/libcore/ffi.rs
Original file line number Diff line number Diff line change
Expand Up @@ -12,24 +12,27 @@ use ::fmt;
/// and `*mut c_void` is equivalent to C's `void*`. That said, this is
/// *not* the same as C's `void` return type, which is Rust's `()` type.
///
/// Ideally, this type would be equivalent to [`!`], but currently it may
/// be more ideal to use `c_void` for FFI purposes.
/// To model pointers to opaque types in FFI, until `extern type` is
/// stabilized, it is recommended to use a newtype wrapper around an empty
/// byte array. See the [Nomicon] for details.
///
/// [`!`]: ../../std/primitive.never.html
/// [pointer]: ../../std/primitive.pointer.html
/// [Nomicon]: https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs
// N.B., for LLVM to recognize the void pointer type and by extension
// functions like malloc(), we need to have it represented as i8* in
// LLVM bitcode. The enum used here ensures this and prevents misuse
// of the "raw" type by only having private variants.. We need two
// of the "raw" type by only having private variants. We need two
// variants, because the compiler complains about the repr attribute
// otherwise.
// otherwise and we need at least one variant as otherwise the enum
// would be uninhabited and at least dereferencing such pointers would
// be UB.
#[repr(u8)]
#[stable(feature = "raw_os", since = "1.1.0")]
pub enum c_void {
#[unstable(feature = "c_void_variant", reason = "should not have to exist",
#[unstable(feature = "c_void_variant", reason = "temporary implementation detail",
issue = "0")]
#[doc(hidden)] __variant1,
#[unstable(feature = "c_void_variant", reason = "should not have to exist",
#[unstable(feature = "c_void_variant", reason = "temporary implementation detail",
issue = "0")]
#[doc(hidden)] __variant2,
}
Expand Down

0 comments on commit eb93f41

Please sign in to comment.