libc::c_void and std::os::raw::c_void are incompatible

[SSheldon]

extern crate libc;

use std::os::raw;
use std::ptr;

fn main() {
    let a: *mut raw::c_void = ptr::null_mut();
    let b: *mut libc::c_void = a;
}

error: mismatched 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`)

Since c_void is defined in the standard library, I'd expect this crate to be compatible with it. Could we change libc::c_void to be a re-export of std::os::raw::c_void?

[alexcrichton]

Yeah this is a currently conscious decision to not reexport what's in the standard library to help the two evolve independently. For example if libc were to reexport everything in the standard library, then each release of libc would have perhaps a new minimum version of Rust it needs to be paired with which may not work for all others. In order to have maximal compatibility with all Rust versions for now, these aren't going to be reexported.

This should be a backwards-compatible change, however, so if it becomes too onerous we can consider adding the reexports at a later date (note that this was an unresolved question in the RFC). For now, though, as this is intentional, I'm going to close this. Thanks for the report, though!

[wthrowe]

Would this change actually be backwards-compatible? It seems that it would break any case where someone had implemented the same trait for std::os::raw::c_void and libc::c_void (or both versions of Foo<c_void> or whatever).

[alexcrichton]

Hm yes that is a good point, that would be a backwards-incompatible change.

[alexcrichton]

(albeit one that I would expect to be pretty unlikely)