Skip to content

OsStr: compare prefix #40300

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

Closed
nagisa opened this issue Mar 6, 2017 · 3 comments
Closed

OsStr: compare prefix #40300

nagisa opened this issue Mar 6, 2017 · 3 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@nagisa
Copy link
Member

nagisa commented Mar 6, 2017

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
@codyps
Copy link
Contributor

codyps commented 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 OsStr due to the limited windows OsStrExt).

@djzin
Copy link
Contributor

djzin commented 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).

@Mark-Simulacrum Mark-Simulacrum added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 27, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@dtolnay
Copy link
Member

dtolnay commented 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 OsStr RFC in rust-lang/rfcs#1309 if anyone is interested in taking that over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants