-
Notifications
You must be signed in to change notification settings - Fork 513
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
Add HSTRING
builder and registry support
#3133
Conversation
Thanks to @riverar for helping me fix that natvis... again. 😂 |
|
||
fn deref(&self) -> &[u16] { | ||
if let Some(header) = self.as_header() { | ||
unsafe { core::slice::from_raw_parts(header.data, header.len as usize) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this expose uninitialized memory? i.e. *HStringBuilder::new(123).unwrap()
is a [u16]
slice whose contents are uninitialized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks for the reminder: #3141
This update adds two features to improve string support and efficiency.
The
HSTRING
type now includes anHStringBuilder
type for pre-allocating and constructing anHSTRING
without requiring an additional copy. This is similar to theWindowsPreallocateStringBuffer
function but implemented directly in Rust, as I did for C++/WinRT back in the day.The
windows-registry
crate now also provideget_hstring
andset_hstring
for reading and writing registry values usingHSTRING
. This is far more efficient than eitherString
orOsString
and is lossless, while still providing convertibility withString
andOsString
.Fixes: #3119