std `c_void` and libc `c_void` are different types

[bluss]

Using libc v0.2.7 and rustc 1.8.0-nightly (34af2de 2016-02-05)

extern crate libc;
fn test() {
    let x = 1 as *mut libc::c_void;
    let y = 1 as *mut std::os::raw::c_void;
    let z = if true { x } else { y };
}

src/lib.rs:26:13: 26:37 error: if and else have incompatible types:
 expected `*mut libc::c_void`,
    found `*mut std::os::raw::c_void`
(expected enum `libc::c_void`,
    found enum `std::os::raw::c_void`) [E0308]
src/lib.rs:26     let z = if true { x } else { y };

These must be compatible, otherwise we cause incompatibilities in the ecosystem.

[alexcrichton]

This is an unresolved question in the design of libc, and it's mostly a libc-specific issue, so I'm going to close in favor of rust-lang/libc#180

Which is to say that the current setup is indeed intentional, and in light of rust-lang/rfcs#1415 if std::os::raw isn't going to expand then we could land the reexport and then all types would match (in theory). (in any case though I think this is still a libc issue)

[bluss]

libc bindings desperately need a single source of truth. Can libcore be the central point? It would put an end to incompatibilities between different libc versions too.

[bluss]

std depending on in-tree libc only enables conflicts between different versions of libc. libcore on the other hand, is guaranteed to be used in only one single version.

[bluss]

As long as you insist this is a libc bug only, we can't have a nice solution. Can you point me to why we cannot define these types in some subcrate of libstd?

[alexcrichton]

We've avoided having these types in libcore, and this basically has to be a libc change as std::os::raw::c_void is stable. Along those lines I don't really see how this is an actionable issue other than serving as a place for discussion, which can also happen in the libc repo.

Do you have a concrete plan of action in mind though that affects libstd?

[bluss]

yes, c_void is stable, but it can move to libcore.

[alexcrichton]

The libs team decided recently that due to how libcore stabilization and interoperability with libstd works we need to be quite careful about stabilizing items in libcore. We also agreed that there needs to be motivation for moving an item to libcore as opposed to simply "this works currently".

I would personally not view this as strong enough motivation as to me the raw types do not belong in libcore, and in general the std::raw types only exist to allow access to the underlying parts of libstd, so they serve no purpose in core. If we could not have them.

If you'd like to have a discussion about moving c_void to libcore, however, then that can indeed perhaps happen here.

[retep998]

Perhaps whenever libc does use std it could simply re-export std::os::raw::c_void instead of defining its own c_void. In #[no_std] situations there wouldn't be an std to have an incompatible type with anyway.

[bluss]

An std-using crate could easily wind up using no_std libc.

[Amanieu]

I think there is a good case for moving these types into libcore to support FFI with freestanding C code which does not use a libc. This is mainly relevant for embedded and/or kernel code, which will be using no_std and will not be able to use the libc crate.

This will also help with removing libstd's dependency on libc on Windows, since most remaining uses of libc in libstd/sys/windows are just the basic C types.

[jmesmon]

Related internals discussion: https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268

[aturon]

I left some thoughts on the internals discussion.

[SimonSapin]

New RFC to propose fixing this through core::ffi::c_void: rust-lang/rfcs#2521

[gnzlbg]

The RFC was merged, implemented, so this should be closed, probably.

[SimonSapin]

Indeed!