std::os::windows::io::RawHandle exposes libc::HANDLE

[klutzy]

std::os::windows::io::RawHandle is a re-export of libc::HANDLE = *mut libc::c_void, and c_void is defined as enum.
So it's possible to access non-primitive type of liblibc via std. This leads to confusing error if someone uses both RawHandle and crates.io's liblibc:

// use libc from crates.io
extern crate libc;
use std::os::windows::io::AsRawHandle;

fn get_handle(file: File) {
    let handle = file.as_raw_handle();

    // error: mismatched types: expected `*mut libc::types::common::c95::c_void`,
    // found `*mut libc::types::common::c95::c_void`
    // let handle: libc::HANDLE = handle;

    // explicit casting needed
    let handle: libc::HANDLE = handle as libc::HANDLE;
}

(On unix, std::os::unix::io::RawFd is re-export of libc::c_int, which is re-export of primitive type.)

[alexcrichton]

I think that rust-lang/rfcs#1044 will fix this as it sets a vision for "raw" types and where they're defined and/or organized. In this case they'll be defined in the std::os::windows::raw where they'll be accessible.

[retep998]

I'd be happy with just having c_void publicly accessible in std.

[klutzy]

This is fixed: liblibc doesn't have HANDLE anymore, and std::os::windows::raw::HANDLE is an alias of *mut c_void.
(Note that c_void itself is still an issue: #31536)