Bringing `OsStr` and `CStr` up to par with `str`

[codyps]

Redirected from rust-lang/rust#22741

Using starts_with() as an example:
Right now one can do this on OsStr by:

• requiring the OsStr to be utf-8 (and converting it to str/String)
• Or implimenting a unix version using as_bytes(), and a windows version using encode_wide()

Unfortunately, the lack of a common method for iteration over elements of the OsStr means that any out-of-std implimentation of these will be un-happily platform specific.

[ben0x539]

It's not clear to me why we can't expose the underlying representation with some sort of .as_bytes(). Is it just because we assume people are gonna assume that on Windows that means it's the active codepage and not WTF-8?

cc @eddyb

[dtolnay]

#1876 discusses some ideas for how slicing could work for CStr.

[dtolnay]

See also:

• Add starts_with and ends_with to OsStr rust#26499, an unmerged implementation of starts_with and ends_with and discussion of generalizing the Pattern API to OsStr.
• OS string string-like interface #1309, a promising RFC involving the OsStr API.
• OsStr: compare prefix rust#40300, discussion of prefix comparison for OsStr.

[dylni]

For everyone still waiting on this issue, I created OsStr Bytes, which should make OsStr and OsString much easier to use.

[BurntSushi]

@dylni I realize you're intentionally invoking UB in that crate, but it's still UB and I therefore wouldn't recommend that approach: https://github.com/dylni/os_str_bytes/blob/ff8a9ed5e7d50b9ff63ea20bfd460a7f481340c1/src/windows.rs#L16-L28

bstr does as much as is possible with as little work as possible without breaking abstraction boundaries or invoking UB: https://docs.rs/bstr/0.2.8/bstr/#file-paths-and-os-strings

[dylni]

@BurntSushi I completely agree and was hoping to hear some opinions on this, which is why I put it on the front page of the documentation. My plan is to come up with something better before a 1.0 release, but I haven't yet decided what the best option would be. However, I don't agree with the approach of not being able to handle some valid arguments on Windows, which is why I created the crate.

I may just end up copying next_code_point() from the standard library, but I haven't decided yet. The problem with this is that bytes could be mangled if the standard library implementation changes, which is why I've avoided it so far.

[dylni]

@BurntSushi That method is no longer called.