Linux: add getitimer()/setitimer()#3847
Linux: add getitimer()/setitimer()#3847nathaniel-bennett wants to merge 1 commit intorust-lang:mainfrom
getitimer()/setitimer()#3847Conversation
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use |
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
8 times, most recently
from
d5924b1 to
f40a7c1
Compare
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
from
f40a7c1 to
e19650d
Compare
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
9 times, most recently
from
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.
not sure I follow, why not using the typedef you created above ?
There was a problem hiding this comment.
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_tdirectly in function definitions causes musl CI to fail as it's not a defined type - Removing
__itimer_which_taltogether for musl builds still causes CI to fail, as there is currently no way of opting out ofenumsemver checks (you can opt out forstructs,types, everything else butenums)
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.
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.
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
6 times, most recently
from
c1c2250 to
97f85ed
Compare
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
6 times, most recently
from
54197ef to
2e751ed
Compare
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
4 times, most recently
from
92adcf7 to
f121cd5
Compare
nathaniel-bennett
force-pushed
the
linux-getitimer-api
branch
from
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.
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.
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 enums 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.
|
@rustbot author based on the above |
|
☔ The latest upstream changes (presumably #4113) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@nathaniel-bennett gentle ping, are you able to update this? |
|
Closing as inactive. Please feel free to reopen if you get back to it! |
6 participants
Resolves #1347