-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std::run::Process::new() should take &[&str] instead of &[~str] #7928
Comments
nominating production ready |
This could probably be |
Just a bug, de-nominating |
I just checked how Process::new works on Linux, and on that platform we cannot do zero-copy exec with |
Do the internals allocate with the current design, or do they reuse the (In any case, I guess these really should take |
@cmr: We shouldn't be forcing callers to allocate just because on one platform we need to allocate internally. |
@kballard we need null-termination on Unix platforms. |
@huonw: Yes, but that's no excuse for requiring the caller to provide a |
It's not one platform. It's also OS X and Windows. If it isn't true on But, on Windows, we build a complete command-line string entirely, it On Mon, Jan 13, 2014 at 7:42 PM, Kevin Ballard notifications@github.comwrote:
|
## Process API The existing APIs for spawning processes took strings for the command and arguments, but the underlying system may not impose utf8 encoding, so this is overly limiting. The assumption we actually want to make is just that the command and arguments are viewable as [u8] slices with no interior NULLs, i.e., as CStrings. The ToCStr trait is a handy bound for types that meet this requirement (such as &str and Path). However, since the commands and arguments are often a mixture of strings and paths, it would be inconvenient to take a slice with a single T: ToCStr bound. So this patch revamps the process creation API to instead use a builder-style interface, called `Command`, allowing arguments to be added one at a time with differing ToCStr implementations for each. The initial cut of the builder API has some drawbacks that can be addressed once issue #13851 (libstd as a facade) is closed. These are detailed as FIXMEs. ## Dynamic library API `std::unstable::dynamic_library::open_external` currently takes a `Path`, but because `Paths` produce normalized strings, this can change the semantics of lookups in a given environment. This patch generalizes the function to take a `ToCStr`-bounded type, which includes both `Path`s and `str`s. ## ToCStr API Adds ToCStr impl for &Path and ~str. This is a stopgap until DST (#12938) lands. Until DST lands, we cannot decompose &str into & and str, so we cannot usefully take ToCStr arguments by reference (without forcing an additional & around &str). So we are instead temporarily adding an instance for &Path and ~str, so that we can take ToCStr as owned. When DST lands, the &Path instance should be removed, the string instances should be revisted, and arguments bound by ToCStr should be passed by reference. FIXMEs have been added accordingly. ## Tickets closed Closes #11650. Closes #7928.
…, r=flip1995 Reference `clippy_utils` docs on nightly-rustc and some other documentation updates The `clippy_utils` crate is now part of the nightly-rustc documentation. See [**very beautiful documentation**](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/). This PR references them in our documentation and updates some other documentation. changelog: none
Right now you have to clone everything into an array instead of just passing pointers. It would be nice if it did the cloning behind the scenes if it really must be done, or better yet, avoid it altogether.
The text was updated successfully, but these errors were encountered: