Convert WaitStatus to/from i32

[rocallahan]

1. I have raw waitpid statuses in a database that I want to be able to parse as WaitStatuses, but decode is not exposed.
2. I want to be able to serialize and deserialize WaitStatuses and going to/from the raw i32 seems like a good way to do that.

[Susurrus]

For 1, you should be able to cast it using as and if that doesn't work you can use mem::transmute.

As for serializing/deserializing, that should really be done by serde. Maybe we could add a feature to derive the relevant traits for appropriate types.

[rocallahan]

For 1, you should be able to cast it using as and if that doesn't work you can use mem::transmute.

I don't understand how this could work without calling decode somehow.

[Susurrus]

Ahh, indeed. Should've looked at the code first!

But i think I need some more context to really understand your use case and whether it should be supported here. So can you explain your use case more? You end up with a WaitStatus, and then what? As far as I can see there's no API inputs that are of type WaitStatus. So why convert them?

[rocallahan]

rr --- https://github.com/mozilla/rr --- records program execution and builds a trace which contains, among other things, process exit codes as reported by waitpid. It's written in C++.

I want to read those codes in a Rust program and then process them e.g. to distinguish regular exit from fatal signals and extract the fatal signal number. nix WaitStatus provides that logic but I can't use it.

(Actually I can only actually use it if the nix Signal type is extended to handle Linux RT signals as well. Right now nix just panics on such signals which is not good...)

[Susurrus]

I'm not entirely convinced this should be supported by nix, but I don't think I fully appreciate the use case. My main concern is that we purposefully encapsulate types in order to prevent invalid types from being created and I don't think i32 is the right intermediary here. Maybe what's better is to implement serde's Serialize/Deserialize traits (or whatever the equivalent are named, I've never used serde) and then you can use that for storing this values in the database and recovering them assuming your ORM would support it. That would be a general-use solution I would endorse including in nix and also remove even more logic from your program, because what you actually want to store are WaitStatus's, not i32s.

But I still have only a very narrow view of this context. I'd suggest you whip up some code to do what we want (for rr as well probably) and then we can iterate on it.

[rocallahan]

rr's written in C++ so I can't use nix there.

Another use-case is if you're writing something like strace in Rust. You'd then want to use ptrace to read memory from the tracee and convert the value into a WaitStatus to interpret it. This in in fact what rr does, so even if it was written in Rust we'd still need this conversion.

My main concern is that we purposefully encapsulate types in order to prevent invalid types from being created

Sure, so have decoding return Result<WaitStatus>.

[Susurrus]

Why don't we go ahead and move on to a PR for this and evaluate it there? Seems like a minimal amount of work to expose a useful new API.

Also, since you speak of strace, I want to ping @geofft here as he's writing gtrace, which is an strace implementation in Rust.

[rocallahan]

Filed #741