As discussed here
https://github.com/rust-lang/rust/pull/88300#issuecomment-936085371
exit is (conventionally) a library function, with _exit being the
actual system call.
I have checked the other references and they say "if the process
terminated by calling `exti`". I think despite the slight
imprecision (strictly, it should read iff ... `_exit`), this is
clearer. Anyone who knows about the distinction between `exit` and
`_exit` will not be confused.
`_exit` is the correct traditional name for the system call, despite
Linux calling it `exit_group` or `exit`:
https://www.freebsd.org/cgi/man.cgi?query=_exit&sektion=2&n=1
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Stabilise unix_process_wait_more, extra ExitStatusExt methods
This stabilises the feature `unix_process_wait_more`. Tracking issue #80695, FCP needed.
This was implemented in #79982 and merged in January.
Provide ExitStatusError
Closes#73125
In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics.
I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
It is unergnomic to have to say things like
bad.into_status().signal()
Implementing `ExitStatusExt` for `ExitStatusError` fixes this.
Unfortunately it does mean making a previously-infallible method
capable of panicing, although of course the existing impl remains
infallible.
The alternative would be a whole new `ExitStatusErrorExt` trait.
`<ExitStatus as ExitStatusExt>::into_raw()` is not particularly
ergonomic to call because of the often-required type annotation.
See for example the code in the test case in
library/std/src/sys/unix/process/process_unix/tests.rs
Perhaps we should provide equivalent free functions for `ExitStatus`
and `ExitStatusExt` in std::os::unix::process and maybe deprecate this
trait method. But I think that is for the future.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>