Split libc into types and impl crates

[vi]

C libraries (including system ones like glibc or musl) change, but C fundamentals stay put.

I expect many FFI bindings may rely only on fundamental language-provided types like size_t and c_void, not on specific library-provided ones like sockaddr or FILE.

To bring more stability to such use case, libc may be split into something like libc-pure with only type-level things that are expected to change when C as a language changes and libc-sys with everything else. libc itself is just a bunch of re-exports.

Exact splitting line and naming details is left to further discussion. A simple no-brainer constraint maybe that unix:notbsd:fexecve and c_int should appear on opposite sides of the barricades.

[gnzlbg]

There has been discussion about exposing a ctypes crate somewhere: rust-lang/rust#36193

It's a bit tricky because c_void is something that one might want to expose in core.

[vi]

As Rust as a language is somewhat defined in C terms (so inherently relies on it), maybe multiple low-level primitive C types should be in core?

If #[repr(C)] directly mentions C, why not core?

[gnzlbg]

Because core is platform-independent while std is platform dependent (and hence why the ctypes are already in std::os::raw). The only ctype that is platform independent is c_void AFAIK.

[gnzlbg]

FYI c_void is already in core::ffi - if you only want ctypes, you should check out the cty crate.