-
Notifications
You must be signed in to change notification settings - Fork 707
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
Bindgen generates different type name for va_list on different systems #2631
Comments
I can confirm this issue, any workaround? I was trying to use https://github.com/dylanmckay/vsprintf for a function that takes
|
You can test this locally eg on aarch64 rustup target add x86_64-apple-darwin
bindgen input.h -- --target=x86_64-apple-darwin
# --target=aarch64-apple-darwin for now I'm working around as #[cfg(not(all(target_os = "macos", target_arch = "aarch64")))]
type VaListType = *mut crate::libpinmame::__va_list_tag;
#[cfg(all(target_os = "macos", target_arch = "aarch64"))]
type VaListType = crate::libpinmame::va_list;
pub unsafe extern "C" fn pinmame_on_log_message_callback(
log_level: u32,
format: *const ::std::os::raw::c_char,
args: VaListType,
_user_data: *const ::std::os::raw::c_void,
) {
let str = unsafe { vsprintf::vsprintf(format, args).unwrap() };
on_log_message(log_level, str);
} Not sure if this also applies to linux/windows aarch64. If some of the devs could confirm this is not a bug but just something we need to handle? |
My packages build out the box on linux/arm64 so this seams to be just a mac thing. |
While I understand this is annoying, there is not much we can do from the bindgen side as clang provides the definitions for these built-in types itself. So the fact that bindgen emits the |
The type name is the same in all c (even if the type is a macro). Is there any way bingen could emit a type elias that's consistent regardless of the underlying type? |
So after a little bit more digging it seems the issue we have here is that on C void foo(int arg[2]); which is translated as pub fn foo(arg: *mut ::std::os::raw::c_int); instead of pub fn foo(arg: *mut [::std::os::raw::c_int; 2]); So this is a particular case of #1561 which was fixed by adding the If I pass this flag to bindgen using the headers you provided, on linux in x86_64 I get the following output: pub type va_list = __builtin_va_list;
extern "C" {
pub fn foo(arg: *mut va_list);
}
pub type __builtin_va_list = [__va_list_tag; 1usize]; Which I think is what you want. Let me know if this is correct or not :) |
That flags changes |
yeah but the name of the type is the same, isn't that what you wanted? |
No, I have my own rust function that takes a VaList then calls a c function that takes a VaList extern "C" fn my_function(args: ?) {
bindgen_generated_function(args)
} I need to be able to declare my function with the right type for the types to match. |
When using libbpf-sys' bindgen feature, the generated va_list type varies on different platforms. Use void pointer as va_list pointer type and transmute pointer of type use va_list pointer instead for cross platform support. See rust-lang/rust-bindgen#2631
When using libbpf-sys' bindgen feature, the generated va_list type varies on different platforms. Use void pointer as va_list pointer type and transmute pointer of type use va_list pointer instead for cross platform support. See rust-lang/rust-bindgen#2631
When using libbpf-sys' bindgen feature, the generated va_list type varies on different platforms. Use void pointer as va_list pointer type and transmute pointer of type that uses va_list pointer for cross platform support. See rust-lang/rust-bindgen#2631
When using libbpf-sys' bindgen feature, the generated va_list type varies on different platforms. Use void pointer as va_list pointer type and transmute pointer of type that uses va_list pointer for cross platform support. See rust-lang/rust-bindgen#2631
Input C/C++ Header
Bindgen Invocation
Actual Results
Expected Results
I expect the name of this type to be the same on both systems regardless of the underlying implementation.
The text was updated successfully, but these errors were encountered: