Always panics on assertion failed.

[hollmmax]

A panic occurs in this crate when using constellation-rs. The crate panics immediately, which makes constellation unusable.
The panic occurs in the assertion in timer.rs:98:13, as reported by backtrace.
After digging a bit I believe this is caused by the cast from time::Instant to timer::Instant, because time::Instant is defined as { i64, u32 }, whereas libc::timespec is defined as { i64, i64 }. This results in garbage data being read in the upper 32 bits of timer::Instant.t.t.tv_nsec. Comparing the mismatched values which triggered the assertion confirms the they do have the same lower 32 bits and the upper 32 bits of tv_nsec are non-zero.

[alecmocatta]

Thanks for surfacing this @hollmmax. I saw this a while back in TWIR and forgot I'd written (horrible) code depending on the layout of Instant.

Do you think there's a way to do this safely? Do we have to forego std::time::Instant compatibility? Or shall we continue the casting hack, and just update to the below?

https://github.com/rust-lang/rust/blob/0c0b403f19fc6febcd1e36a83fc307ecc11de943/library/std/src/sys/unix/time.rs#L12-L27

[hollmmax]

I didn't dig deeper into why and how std::time::Instant compatibility is used, but it is, so I'll assume that dropping support for it would be more work elsewhere.
I'm also not sure what you mean by updating to the current std::time::Instant, because the problem comes from the difference between std::time::Instant and nix::libc::timespec.