Skip to content

Commit 8b8c576

Browse files
authored
Rollup merge of rust-lang#56594 - sdroege:c_void-is-not-never, r=TimNN
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.
2 parents 38650b6 + 8de8880 commit 8b8c576

File tree

1 file changed

+10
-7
lines changed

1 file changed

+10
-7
lines changed

src/libcore/ffi.rs

+10-7
Original file line numberDiff line numberDiff line change
@@ -12,24 +12,27 @@ use ::fmt;
1212
/// and `*mut c_void` is equivalent to C's `void*`. That said, this is
1313
/// *not* the same as C's `void` return type, which is Rust's `()` type.
1414
///
15-
/// Ideally, this type would be equivalent to [`!`], but currently it may
16-
/// be more ideal to use `c_void` for FFI purposes.
15+
/// To model pointers to opaque types in FFI, until `extern type` is
16+
/// stabilized, it is recommended to use a newtype wrapper around an empty
17+
/// byte array. See the [Nomicon] for details.
1718
///
18-
/// [`!`]: ../../std/primitive.never.html
1919
/// [pointer]: ../../std/primitive.pointer.html
20+
/// [Nomicon]: https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs
2021
// N.B., for LLVM to recognize the void pointer type and by extension
2122
// functions like malloc(), we need to have it represented as i8* in
2223
// LLVM bitcode. The enum used here ensures this and prevents misuse
23-
// of the "raw" type by only having private variants.. We need two
24+
// of the "raw" type by only having private variants. We need two
2425
// variants, because the compiler complains about the repr attribute
25-
// otherwise.
26+
// otherwise and we need at least one variant as otherwise the enum
27+
// would be uninhabited and at least dereferencing such pointers would
28+
// be UB.
2629
#[repr(u8)]
2730
#[stable(feature = "raw_os", since = "1.1.0")]
2831
pub enum c_void {
29-
#[unstable(feature = "c_void_variant", reason = "should not have to exist",
32+
#[unstable(feature = "c_void_variant", reason = "temporary implementation detail",
3033
issue = "0")]
3134
#[doc(hidden)] __variant1,
32-
#[unstable(feature = "c_void_variant", reason = "should not have to exist",
35+
#[unstable(feature = "c_void_variant", reason = "temporary implementation detail",
3336
issue = "0")]
3437
#[doc(hidden)] __variant2,
3538
}

0 commit comments

Comments
 (0)