The documentation for std::ffi::OsString says—
On Windows, [platform-native] strings are often arbitrary sequences of non-zero 16-bit values, interpreted as UTF-16 when it is valid to do so.
The documentation for std::ffi § "Representations of non-Rust strings" says—
- OsString represents an owned string in whatever representation the operating system prefers. [...]
- OsStr represents a borrowed reference to a string in a format that can be passed to the operating system. [...]
These statements led me to understand that—
- on Microsoft Windows, an
OsString would represent its text as "arbitrary sequences of non-zero 16-bit values", and not as UTF-8, and thus
- on Windows, an
OsStr would reference such a non-UTF-8 sequence, and thus
OsStr::to_str — which returns an Optional &str that (by my imperfect understanding of Rust reference rules) would have to reference the same thing as the OsStr — almost always would return None on Windows (except for, e.g., empty strings), because a Windows string could not validly be read as a Rust str.
However, @retep998 tells me that—
- "OsStr::to_str on Windows will succeed most of the time",
OsString stores its text in WTF-8 on Windows, and-
it's more accurate [than what the std::ffi documentation says] to say that OsStr represents an owned string in a representation capable of handling any string received from the operating system
not necessarily the same encoding as what the operating system uses, but it can losslessly transcode back and forth
Was my misinterpretation of the documentation unreasonable? If not, could the documentation be clarified on this point?
The documentation for
std::ffi::OsStringsays—The documentation for
std::ffi§ "Representations of non-Rust strings" says—These statements led me to understand that—
OsStringwould represent its text as "arbitrary sequences of non-zero 16-bit values", and not as UTF-8, and thusOsStrwould reference such a non-UTF-8 sequence, and thusOsStr::to_str— which returns anOptional&strthat (by my imperfect understanding of Rust reference rules) would have to reference the same thing as theOsStr— almost always would returnNoneon Windows (except for, e.g., empty strings), because a Windows string could not validly be read as a Ruststr.However, @retep998 tells me that—
OsStringstores its text in WTF-8 on Windows, andWas my misinterpretation of the documentation unreasonable? If not, could the documentation be clarified on this point?