You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
POSIX defines the following fields on siginfo_tlink:
int si_signo Signal number.
int si_code Signal code.
int si_errno If non-zero, an errno value associated with
this signal, as described in <errno.h>.
pid_t si_pid Sending process ID.
uid_t si_uid Real user ID of sending process.
void *si_addr Address of faulting instruction.
int si_status Exit value or signal.
long si_band Band event for SIGPOLL.
union sigval si_value Signal value.
Of particular interest to me are si_signo, si_code (which are already exposed everywhere), as well as si_pid and si_status. These allow asynchronously receiving the exit status of a child process via SIGCHLD.
However, on x86_64-unknown-netbsd (documented here) and x86_64-unknown-openbsd (undocumented but exists here) , these fields are not exposed in any way. on x86_64-unknown-linux-gnu they are exposed as unsafe methods, and on x86_64-unknown-freebsd, as regular struct fields and unsafe methods.
I understand that this is due to some implementations choosing to use unions, or having different struct field orders. It would be very helpful if there was a consistent, portable way to access them, or at the very least, expose them on those two targets.
The text was updated successfully, but these errors were encountered:
POSIX defines the following fields on
siginfo_t
link:Of particular interest to me are
si_signo
,si_code
(which are already exposed everywhere), as well assi_pid
andsi_status
. These allow asynchronously receiving the exit status of a child process via SIGCHLD.However, on
x86_64-unknown-netbsd
(documented here) andx86_64-unknown-openbsd
(undocumented but exists here) , these fields are not exposed in any way. onx86_64-unknown-linux-gnu
they are exposed as unsafe methods, and onx86_64-unknown-freebsd
, as regular struct fields and unsafe methods.I understand that this is due to some implementations choosing to use unions, or having different struct field orders. It would be very helpful if there was a consistent, portable way to access them, or at the very least, expose them on those two targets.
The text was updated successfully, but these errors were encountered: