-
Notifications
You must be signed in to change notification settings - Fork 746
use_core option to imply nostd and deny any ::std:: #628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
There are two options: |
I'm processing a low-level library (CMSIS/STM32 HAL). And I get the output
full of `::std::os::raw::c_uint` types. I suggest that they should be
replaced with libcore types. Possible?
|
Is |
FYI: the library is libc-independent. And I assume rs code should be alike.
|
Related: rust-lang/rfcs#1783 |
Transforming `::std::os::raw::c_uint` -> `u32` is fine for me, but it seems
impossible with bindgen options, right?
But AFAIU uint isn't completely equal to u32 (arch-dependent), so the full
solution should take this into account too.
|
You can create a submodule in your crate as follows: mod c_types {
type c_uint = u32;
// ...
} And call bindgen with |
I'm closing this because I'm not sure there's anything else I can do from bindgen. Thanks for reporting! |
Em, excuse me. But `::std::os::raw::c_uint` -> `u32`could be done. Or am I
getting it wrong and you suggest it must be done with c_types
workaround/c_types crate?
|
Yes, I believe so, hardcoding types for a single platform isn't something that should happen on bindgen. |
I need
#![no_std]
rust source. I suggest thatuse-core
should help but nowuse-core
produces lots of::std::
code. Ifuse-core
isn't good for the goal maybe it's worth introducing another option?The text was updated successfully, but these errors were encountered: