[WIP] Import C types from the cty crate #1285
Conversation
Fix mixed signed / unsigned types
Add NVPTX architecture
change c_{,u}long to match libc v0.2.23 definitions
add MSP430 support
Copied a few extra definitions from the libc crate.
Include additional types from libc Copied a few extra definitions from the libc crate.
11: Re-export core::ffi::c_void r=japaric a=jeikabu japaric/cty#10 Without this trying to use bindgen like: ```rust let bindings = bindgen::Builder::default() .header("wrapper.h") .ctypes_prefix("cty") .use_core() .generate(); ``` Results in lots of: ``` error[E0308]: mismatched types --> runng/src/protocol/mod.rs:49:43 | 49 | let res = nng_setopt(socket, opt, topic_ptr, topic_size); | ^^^^^^^^^ expected enum `cty::c_void`, found enum `std::ffi::c_void` | = note: expected type `*const cty::c_void` found type `*const std::ffi::c_void` ``` Co-authored-by: jake <jeikabu@gmail.com>
|
@gnzlbg: no appropriate reviewer found, use r? to override |
| // FIXME: ?? | ||
| pub type wchar_t = i32; | ||
| } else { | ||
| pub type wchar_t = u32; |
There was a problem hiding this comment.
Windows also supports aarch64 and arm where wchar_t is still u16.
There was a problem hiding this comment.
I think wchar_t is just too OS and target-dependent to try to shoe-horn it here.
|
I would personally pretty strongly discourage this. The Duplication may be unfortunate but it doesn't matter except for the |
|
After doing this the feeling I got is that it makes more sense to keep both of these crates separate (not change libc to re-export cty), though I'd prefer to host the cty crate here so that we can use libc's CI to make sure its types are correct, both by using I don't think any change here is going to be RFC worthy. The Unsafe Code Guidelines is already documenting that some Rust types exactly match some C types (e.g. |
|
In terms of hosting I don't think it matters too much where it lives, but I think structurally these should continue to be separate crates for the time being (although an RFC could change that) |
|
So i'm closing this to submit a different PR that does that, don't want to lose this branch because it discovered a couple of bugs. |
So this is more or less how solving japaric/cty#13 and japaric/cty#14 would look like. I've kept the whole history of the cty crate.
I think that I found some bugs in both libc and cty in the process.
cc @japaric @Amanieu @retep998 @alexcrichton @denzp