Closed
Description
On Windows, filenames (and many other strings) are stored in UCS-2, not UTF-8. This corresponds to WTF-8, not UTF-8. Furthermore, the NT kernel uses length-specified strings via the UNICODE_STRING
struct, and uses only \
as the path separator. Therefore, many APIs (such as NtCreateFile
and NtCreateKey
) actually allow NUL characters in names. While the NTFS driver does not allow NUL to be part of a filename, registry keys can have NUL characters in there names.
Therefore, I propose that OsStr
on Windows be able to be created from any valid WTF-8, and that an API be provided that allows them to be created with NUL characters.
Also see #53261 (comment)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
ollie27 commentedon Nov 22, 2018
Are
OsStrExt
andOsStringExt
instd::os::windows::ffi
not sufficient?retep998 commentedon Nov 23, 2018
OsStr
literally already is this. It stores WTF-8 instead of UTF-8 and is capable of holding NUL characters just fine.estebank commentedon Jan 11, 2019
Leaving open as under the purview of @rust-lang/docs, like #53261.
Mark-Simulacrum commentedon Aug 6, 2019
Closing since this seems to be satisfied by the existing APIs (per above comments and reading the API docs today). #53261 touches on the more specific issue of
std::ffi
docs being misleading about the underlying representation ofOsString
on Windows, but that's an orthogonal and separate concern.