Process ids are i32 in Linux, std::process::Child::id uses u32

[marmistrz]

See the original report against the nix crate here: nix-rust/nix#656

[retep998]

Does this really matter, especially since that method is stable? It is trivial to cast between i32 and u32 and there's no information loss, so this doesn't seem like enough of a problem to warrant a breaking change in an API that has been stable since Rust 1.3

[GuillaumeGomez]

We could just add a wrapper around it?

[GuillaumeGomez]

So I opened a PR to show what it'd look like. But since it's a stable API...

[kennytm]

You could compare branches without opening a PR.

[GuillaumeGomez]

@kennytm: Ah my bad. Well now it's done...

[alexcrichton]

Thanks for the report, but this was an intentional decision and as a stable method we can't change it, so closing.

[marmistrz]

@alexcrichton what was the intention behind it? Why not keep it open with milestone Rust 2.0 (i.e. when we go so far that we have to break the source API, we'll fix that by the way)

[kennytm]

@marmistrz Those feature requests are still closed, but tagged as rust-2-breakage-wishlist.

[alexcrichton]

@marmistrz no known valid pids are negative and I believe Windows uses u32 natively, so we chose to use u32 across the board.

[marmistrz]

That's not true, for example on Minix: http://wiki.minix3.org/doku.php?id=gentleintroduction

[alexcrichton]

Can a kernel process be a child process?

[marmistrz]

It won't be a problem in Minix:

<marmistrz> I'm wondering if there's a slightest possibility of this affecting any user space processes
<Saturn> it is not. kernel tasks do not have pids at all
<Saturn> the wiki page you linked is talking strictly about what ps is showing, which is no longer true anyway
<Saturn> most importantly, http://pubs.opengroup.org/onlinepubs/9699919799/ defines process IDs as positive
<Saturn> er, http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_300 specifically