Conflict with std's `c_void`

[bluss]

This issue is also reported against Rust. rust-lang/rust/issues/31536

---

Using libc v0.2.7 and rustc 1.8.0-nightly (34af2de40 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.

[gnzlbg]

This an #48 look like duplicates to me, or at least part of the same overarching theme: "we need to get c_void right". I think it might be worth it to coalesce these issues into one now that extern type is implemented.

[bluss]

@gnzlbg Rust's std also needs to be part of fixing this, I don't agree it is a duplicate. Great that you want to fix c_void, though!

[gnzlbg]

Oh yes, they are not exactly duplicates, #48 is about a better way to define c_void, and this is about "there should only be one c_void" (more or less).

From having read all the ctypes discussion, it looks to me that "improving" c_void can be done independently of all other ctypes, and that maybe it might be worth it to collect the problems into an issue that focus exclusively on fixing c_void (putting it in core, with an appropriate type definition using extern type, and re-export that in std and here "somehow").

I think that trying to fix std::os::raw, ctypes, ... is a much tougher problem, and it at least looks to me that c_void doesn't need to be blocked by any of that (it does not make sense to expose ctypes in core but it does make sense to expose c_void there).

[SimonSapin]

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

[gnzlbg]

That RFC was merged, and libc already re-exports core::ffi::c_void. Thank you @SimonSapin !