Since the types in std::os::raw are not also in core, there’s no way to use them from a no-std program. Among other things, this is an issue for bindgen.
Is there a reason we should add a similar module to core (and maybe make the std types aliases for those)?
I was going to saw “but wait OsString is alloc!” but, as always, I forget it’s in std::ffi, not std::os. Those are all type aliases (except c_void which is special), so moving them to core is probably a trivial change.
Since the types in std::os::raw are not also in core, there’s no way to use them from a no-std program. Among other things, this is an issue for bindgen.
FWIW, there is a way to use it from a #[no_std] program, which is using the libc crate, or at least that's the way you used to be able to do it IIRC 
. That's why bindgen has two different options, one to use core, and another to add a prefix for C-types, which usually is libc.
It's not the first report about this being confusing, so a nicer solution would be really appreciated. Though that may mean more requirements for #[no_std] targets which also don't need C types? Not sure about the trade-off here.
Ah, I see. That's a good point.
I don't think it introduces any extra requirements since none of these are extern declarations. They just happen to have the same memory layout as the equivalent C types.
I've put up a PR here.
New RFC to propose doing this for c_void (only, for now): https://github.com/rust-lang/rfcs/pull/2521
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.