mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rollup merge of #82464 - ehuss:unix-command-comment, r=kennytm

Browse Source 
Update outdated comment in unix Command.

The big comment in the `Command` struct has been incorrect for some time (at least since #46789 which removed `envp`). Rather than try to remove the allocations, this PR just updates the comment to reflect reality. There is an explanation for the reasoning at https://github.com/rust-lang/rust/pull/31409#issuecomment-182122895, discussing the potential of being able to call `Command::exec` after `libc::fork`.  That can still be done in the future, but I think for now it would be good to just correct the comment.
This commit is contained in:
Aaron Hill 2021-02-25 16:06:20 -05:00 committed by GitHub
commit 503d50b94c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
library/std/src/sys/unix/ext/process.rs
View File

@ -172,6 +172,8 @@ impl CommandExt for process::Command {
} }
fn exec(&mut self) -> io::Error { fn exec(&mut self) -> io::Error {
// NOTE: This may *not* be safe to call after `libc::fork`, because it
// may allocate. That may be worth fixing at some point in the future.
self.as_inner_mut().exec(sys::process::Stdio::Inherit) self.as_inner_mut().exec(sys::process::Stdio::Inherit)
} }

22
library/std/src/sys/unix/process/process_common.rs
View File

@ -60,25 +60,13 @@ cfg_if::cfg_if! {
//////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////
pub struct Command { pub struct Command {
// Currently we try hard to ensure that the call to `.exec()` doesn't
// actually allocate any memory. While many platforms try to ensure that
// memory allocation works after a fork in a multithreaded process, it's
// been observed to be buggy and somewhat unreliable, so we do our best to
// just not do it at all!
//
// Along those lines, the `argv` and `envp` raw pointers here are exactly
// what's gonna get passed to `execvp`. The `argv` array starts with the
// `program` and ends with a NULL, and the `envp` pointer, if present, is
// also null-terminated.
//
// Right now we don't support removing arguments, so there's no much fancy
// support there, but we support adding and removing environment variables,
// so a side table is used to track where in the `envp` array each key is
// located. Whenever we add a key we update it in place if it's already
// present, and whenever we remove a key we update the locations of all
// other keys.
program: CString, program: CString,
args: Vec<CString>, args: Vec<CString>,
/// Exactly what will be passed to `execvp`.
///
/// First element is a pointer to `program`, followed by pointers to
/// `args`, followed by a `null`. Be careful when modifying `program` or
/// `args` to properly update this as well.
argv: Argv, argv: Argv,
env: CommandEnv, env: CommandEnv,