-
Notifications
You must be signed in to change notification settings - Fork 497
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
Should windows_registry::Key::(get|set)_string
use OsStr
instead of str
?
#3119
Comments
How about this: #3120 It allows you to gracefully handle registry values even when their byte values are not necessarily valid or corresponding to their purported type. You can thus query a "string" value as bytes and interpret it however you wish. Let me know what you think. |
@kennykerr Thanks for the quick response! After a quick look it seems that this only solves half the problem though: since we're modifying the I still personally prefer the
|
How about if we added |
@kennykerr Sounds good! |
#3121 adds |
Hi, and thanks for making this project!
Background
Coming from rust-lang/rustup#3896, we (the Rustup team) are currently evaluating the possibility of replacing
winreg
withwindows-registry
in Rustup. This is mainly because we use the registry APIs to inspect and change thePATH
variable, which is a necessary step in Rustup's installation process.However, the following function signatures look a bit concerning:
windows-rs/crates/libs/registry/src/key.rs
Line 245 in 2ec4e06
windows-rs/crates/libs/registry/src/key.rs
Line 95 in 2ec4e06
... which is because being valid UTF8 is a core invariant of the
str
type. OTOH, it seems to me that there's no guarantee that we should always get/set valid UTF16LE from/to the registry, and we'd like to make sure that Rustup is still working correctly even if there are non-Unicode bytes in the registry value in question (which could be added by a third-party app?).For example, we now have the following smoke test that inserts into the registry a sequence of
u16
that would be considered malformed UTF16LE, and it's expected to work:https://github.com/rust-lang/rustup/blob/4c3ff9ce638e8402fbc2e8755d9e8a2cd148f6be/tests/suite/cli_paths.rs#L427-L440
Suggestion
For the exact reason explained above, I believe
OsStr
/OsString
is a better alternative tostr
/String
in APIs like this.Quoting https://doc.rust-lang.org/std/ffi/struct.OsString.html:
Once that change is made, we would be able to use
windows::ffi::OsStringExt::from_wide
to construct anOsString
from any&[u16]
.I'm still not very familiar with Windows development myself, so please feel free to correct me if I'm wrong about anything.
Many thanks in advance!
The text was updated successfully, but these errors were encountered: