Add OsStringExt::from_wide_ptr for windows

[bozaro]

This method is like CStr::from_ptr for wchar_t* null-terminated strings

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Thanks for the PR!

I'd feel a little uneasy about adding this as I think it's conflating the concept of a "C wide string" and an "OS string". For the standard library an OS string does not guarantee nor require a trailing nul, but a C string does (as do wide C strings). In some sense I think we may want a WideString or CWideString type which is the exact same interface as CString except with s/u8/u16/. That way this'd just be CWideStr::from_ptr(...) and you'd pass that to from_wide, like you do with CString and OsString::from_bytes today.

That's a pretty weighty addition, though, so we may not want to tackle it just yet. Thoughts from others on @rust-lang/libs?

[retep998]

Most of the time, when getting strings from windows API, you usually provide the buffer yourself. It is somewhat rare for Windows API to return a pointer to a buffer that you don't own. If anything, a from_wide_null which took a slice and only read up to the first null terminator would be more useful. Having a from_wide_ptr but not a from_wide_null may cause people to use from_wide_ptr even when they own the buffer and so should use something like from_wide_null.

[bozaro]

@alexcrichton
C++ std::wstring type defined as std::basic_string<wchar_t>, but sizeof(wchar_t) is platform depended (4 bytes on Linux, 2 bytes on Windows). In this case CWideString can't have platform independed signature.

[aturon]

@alexcrichton I agree that, in terms of fitting with existing std practice, we'd want to isolate a separate CString-like type here.

[retep998]

Would this CWideString type actually wrap [u16], so that you could pass them directly to winapi functions without having to convert to and from WTF-8? It would likely have to be Windows specific though, it doesn't make sense on any other platforms, aside from UEFI.

This sounds like a perfect opportunity for someone _cough_ to flesh out the design in an external crate and then have an RFC to merge it into std.

[bozaro]

Ok. I'm starting to write RFC for CWideString. It will take some time.

[alexcrichton]

Ok, I'm gonna close this in favor of a future pending RFC, but thanks regardless for the PR @bozaro!

[bozaro]

Sorry for a long delay, but I created RFC: rust-lang/rfcs#1773

[alexcrichton]

Thanks @bozaro!