-
Notifications
You must be signed in to change notification settings - Fork 758
Closed as duplicate of#3179
Description
Hi!
We have observed the following behavior when generating bindings for the Linux kernel:
test_a.h
:
enum foo {
BAR,
BAZ,
};
bindgen test_a.h
:
/* automatically generated by rust-bindgen 0.71.1 */
pub const foo_BAR: foo = 0;
pub const foo_BAZ: foo = 1;
pub type foo = ::std::os::raw::c_uint;
test_b.h
extern enum foo do_something(void);
enum foo {
BAR,
BAZ,
};
bindgen test_b.h
:
/* automatically generated by rust-bindgen 0.71.1 */
unsafe extern "C" {
pub fn do_something() -> foo;
}
pub const foo_BAR: foo = 0;
pub const foo_BAZ: foo = 1;
pub type foo = i32;
The type of foo
has changed.
This leads to some confusion, because depending on kernel configuration, include files might change ordering. We currently fix this by using as
casts when we use constants that are affected:
/// Restart policy for timers.
#[derive(Copy, Clone, PartialEq, Eq, Debug)]
#[repr(u32)]
pub enum HrTimerRestart {
/// Timer should not be restarted.
#[allow(clippy::unnecessary_cast)]
NoRestart = bindings::hrtimer_restart_HRTIMER_NORESTART as u32,
/// Timer should be restarted.
#[allow(clippy::unnecessary_cast)]
Restart = bindings::hrtimer_restart_HRTIMER_RESTART as u32,
}
Is there anything we can do to prevent this behavior?
Metadata
Metadata
Assignees
Labels
No labels