Closed decathorpe closed 6 months ago
POSIX doesn't dictate the actual structure of the struct sigaction
, this looks like an unfortunate consequence of that.
One way around this would be to change the literal struct initialisation to something involving creating an "zeroed" sigaction
, e.g.:
libc::sigaction {
sa_sigaction,
sa_mask: sa_mask.raw,
sa_flags,
sa_restorer: None,
.. unsafe { std::mem::zeroed::<libc::sigaction>() }
}
This is not very "Rusty", of course. But with C glasses on I even think: how nice to have these bytes at least start out as zero instead of something indeterminate. Perhaps you can verify that this fixes the compilation issue?
Nope, this does not work:
error[E0451]: field `__glibc_reserved0` of struct `sigaction` is private
--> src/system/signal/set.rs:42:20
|
42 | .. unsafe { std::mem::zeroed::<libc::sigaction>() }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ field `__glibc_reserved0` is private
error[E0451]: field `__glibc_reserved0` of struct `sigaction` is private
--> src/system/term/user_term.rs:81:12
|
81 | .. unsafe { std::mem::zeroed::<libc::sigaction>() }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ field `__glibc_reserved0` is private
error[E0451]: field `__glibc_reserved0` of struct `sigaction` is private
--> src/system/term/user_term.rs:246:16
|
246 | .. unsafe { std::mem::zeroed::<libc::sigaction>() }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ field `__glibc_reserved0` is private
For more information about this error, try `rustc --explain E0451`.
error: could not compile `sudo-rs` (lib) due to 3 previous errors
Okay, I missed the fact that you said the hidden field is private as well. In that case a "builder" approach should work. I'll prepare a PR for this later today so that you can test easily if that resolves the feature.
@decathorpe Can you look at #830 and see if the code in that branch fixes the compilation issue?
It looks like the
libc::sigaction
struct has private fields on s390x and cannot be constructed with literal struct initialization:I'm not sure if this is intentional or a bug in the libc crate, since I don't see another way to construct the type.