Switch to manual trait impls for sigevent

[Susurrus]

sigevent on most platforms have padding or unused fields. Rather
than display those in the Debug impl by deriving it, manually implement
all extra_traits instead ignoring those fields.

I do worry that my PartialEq implementations for this for some platforms (like Linux) is not correct due to ignoring bytes that shouldn't be ignored because these structs don't have a proper union set up.

cc @asomers
Part of nix-rust/nix#1035

[rust-highfive]

r? @gnzlbg

(rust_highfive has picked a reviewer for you, use r? to override)

[gnzlbg]

FWIW it might be that sigevent is broken anyways (there are few types that we skip testing everywhere), but sigevent, sig_t/sighandler_t, etc. are usually amongst them.

Looking at the type, does the function pointer field need to always be a non-null pointer ? If one can set that field to NULL in C, then this needs to be an Option in Rust, etc.

[asomers]

Apart from the NULL function pointer issue that @gnzlbg raised, this LGTM.

[Susurrus]

@gnzlbg Are you referring to the sigev_notify_function field that's only exposed on Fuchsia? The function pointer fields for all other platforms are private members, so can't be called even if they're initialized properly. I can change all of these fields to be Option's if that's what you want, however then I think we need to use NonNull if we want to preserve the layout guarantees of these structs.

[gnzlbg]

@bors: r+

[bors]

📌 Commit 7c26591 has been approved by gnzlbg

[bors]

⌛ Testing commit 7c26591 with merge 11c762c...

[gnzlbg]

Are you referring to the sigev_notify_function field that's only exposed on Fuchsia?

Not only, in other platforms there are fields with type *mut c_void that are actually function pointers.

I can change all of these fields to be Option's if that's what you want, however then I think we need to use NonNull if we want to preserve the layout guarantees of these structs.

Function pointers (fn()->()) in Rust are always NonNull. That is, initializing one to zero invokes undefined behavior instantaneously. An Option<fn()->()> has the same layout of a pointer, and Option::None represents the null pointer.

---

Another issue I am seeing is that these function pointers are not extern "C". So they should actually probably be of type Option<extern "C" unsafe fn(...)->...>.

[bors]

☀️ Test successful - checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-travis, status-appveyor
Approved by: gnzlbg
Pushing 11c762c to master...