-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Linux: add getitimer()
/setitimer()
#3847
base: main
Are you sure you want to change the base?
Linux: add getitimer()
/setitimer()
#3847
Conversation
r? @JohnTitor rustbot has assigned @JohnTitor. Use |
d5924b1
to
f40a7c1
Compare
f40a7c1
to
e19650d
Compare
8897989
to
7d33aff
Compare
cfg_if! { | ||
if #[cfg(target_env = "musl")] { | ||
extern "C" { | ||
pub fn getitimer(which: ::c_int, value: *mut ::itimerval) -> ::c_int; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure I follow, why not using the typedef you created above ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the result of a strange combination of issues. glibc and most other libc implementations typedef __itimer_which_t
as an enum
when _GNU_SOURCE
is set, or as an int
otherwise. musl unfortunately opts to just use an int
directly within the function definitions for getitimer
and setitimer
. As a result of this:
- Using
__itimer_whiich_t
directly in function definitions causes musl CI to fail as it's not a defined type - Removing
__itimer_which_t
altogether for musl builds still causes CI to fail, as there is currently no way of opting out ofenum
semver checks (you can opt out forstruct
s,type
s, everything else butenum
s)
By defining __itimer_which_t
as a type
definition in musl
and then opting out of it, CI passes.
A more clean solution to this may be to develop enum
opt-out functions to the ctest2
crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another possible approach is not to bother with enums at all.
pub type __itimer_which_t = ::c_int;
...
pub const ITIMER_REAL: __itimer_which_t = 0;
...
There are various places in this crate were C enums are handled as simple constants. Should pass in theory.
c1c2250
to
97f85ed
Compare
54197ef
to
2e751ed
Compare
92adcf7
to
f121cd5
Compare
f121cd5
to
a3e2201
Compare
r? @tgross35 |
cfg_if! { | ||
if #[cfg(target_env = "musl")] { | ||
pub type __itimer_which_t = ::c_int; | ||
} else { | ||
pub type __itimer_which_t = ::c_uint; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
glibc has int
when it is not defined as an enum, and musl doesn't seem to define this type at all - why is the definition done this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nevermind, I see the reasoning below. I think we need to work with one of the ways that doesn't expose this on musl.
In general it is probably better to avoid Rust enum
s to represent C types at all, given how easy it is to cause UB. So some sort of solution that just typedefs an int on glibc seems preferable to me.
Resolves #1347