Consistent wrapper over siginfo_t

[gnzlbg]

The API of the libc::signinfo_t type is platform dependent, and currently nix exposes this type "as is" to users.

For example, on many OSes (MacOS, *BSDs, etc.) siginfo_t is a struct that has a si_addr struct field, but on Linux, for example, si_addr is not a struct field. Instead, linux contains an union fields, that has some more fields, that have some more fields, and one of them is si_addr. Linux provides a C macro to access this field, and in libc we provide a method on siginfo_t for that.

This means that, depending on the target platform, users using the siginfo_t type re-exported by nix need to perform either field access, or call a method, which is not very consistent.

si_addr is not the only siginfo_t field which is different on Linux.

---

One idea would be for nix to just have a #[repr(transparent)] struct siginfo_t(libc::siginfo_t); type wrapper that always exposes methods instead, and to use #[cfg]s inside the methods to map to whatever layout the operating system being targeted uses.

[asomers]

Yeah, we probably shouldn't allow field access at all, to ensure a consistent API. One complicating factor is those unions. Rust didn't have any kind of union support when they were added to libc, but it does now. Nix should use an API that will still work if libc starts using unions.

[gnzlbg]

Yeah, we probably shouldn't allow field access at all, to ensure a consistent API.

It might make sense to always do this, for all types nix re-exports, except for primitive types like libc::{c_int, c_void, ...}. One can always let users access the inner platform-specific types if they want to, but then at least users would be explicitly opting into potentially non-portable code.