libc types exposed by libstd #29774
Comments
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Nov 11, 2015
It's a bit strange to expect users of `libstd` to require the use of an external crates.io crate to work with standard types. This commit encourages the use `os::raw::c_char` instead, although users are certainly free to use `libc::c_char` if they wish; the test still exists to ensure the two types are identical (though the reported bug only exists on platforms that are not officially tested). Fixes rust-lang#29774
This was referenced Dec 3, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The libc merge was a breaking change:
c_charon ARM Linux was i8 but is now u8. This is a bugfix, which is fair, it was wrong before. This type is exposed via CStr::as_ptr() however, and there was no obvious way to refer to it, so users would depend on and use the crates.iolibc::c_char, which only corresponds if using (old rustc + libc 0.1) or (new rustc + libc 0.2).Note that os::raw::c_char is still wrong/old, so even using that would break.
cc @alexcrichton
The text was updated successfully, but these errors were encountered: