You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OsStr could implement a way to compare against prefix &str (as it does not implement iterators over its data), similarly to how it implements comparison against &str.
Currently you need to go out of your way to convert to bytes. as_str is not suitable, as following case shows:
let x = /* OsStr with invalid utf8 */;
x.as_str().map(|x| x.starts_with("-")).unwrap_or(false); // false even if only the first byte really matters
Older related issue: #26499 (there are quite a few about expanding the OsStr api, seems to be a continuous pain point).
I've put together a crate (os-str-generic), to fill some of these holes, but due to not having access to the underlying representation it will always have certain in-efficiencies (can't generally create references to "slices" of an OsStr due to the limited windows OsStrExt).
I came across a whole bunch of these seeing what it would take to have rustc handle non-utf8 paths (It is a deep, deep pit of madness. Demons lie there. Do not enter). Basically a lot of argument-handling code relies on comparing substrings and suchlike, and there is no way to do it for OsStr because of the barmy way Windows handles strings.
Unfortunately, this leaves us in the position where, in trying to do everything "correctly" in handling OsStr, PathBuf & co, it is just far more ergonomic for users to use to_str().unwrap() (or one of the methods that calls it implicitly), making basically every rust program crash on non-utf8 paths, environment variables etc. - a worse situation in my mind than not handling utf-8 at all (i.e. only having byte strings).
I believe this is going to require an RFC. Let's track this in rust-lang/rfcs#900. There is a promising start to an OsStr RFC in rust-lang/rfcs#1309 if anyone is interested in taking that over.
Activity
codyps commentedon Mar 6, 2017
Older related issue: #26499 (there are quite a few about expanding the OsStr api, seems to be a continuous pain point).
I've put together a crate (os-str-generic), to fill some of these holes, but due to not having access to the underlying representation it will always have certain in-efficiencies (can't generally create references to "slices" of an
OsStrdue to the limited windowsOsStrExt).djzin commentedon Mar 6, 2017
I came across a whole bunch of these seeing what it would take to have rustc handle non-utf8 paths (It is a deep, deep pit of madness. Demons lie there. Do not enter). Basically a lot of argument-handling code relies on comparing substrings and suchlike, and there is no way to do it for OsStr because of the barmy way Windows handles strings.
Unfortunately, this leaves us in the position where, in trying to do everything "correctly" in handling OsStr, PathBuf & co, it is just far more ergonomic for users to use
to_str().unwrap()(or one of the methods that calls it implicitly), making basically every rust program crash on non-utf8 paths, environment variables etc. - a worse situation in my mind than not handling utf-8 at all (i.e. only having byte strings).dtolnay commentedon Nov 17, 2017
I believe this is going to require an RFC. Let's track this in rust-lang/rfcs#900. There is a promising start to an
OsStrRFC in rust-lang/rfcs#1309 if anyone is interested in taking that over.