-
Notifications
You must be signed in to change notification settings - Fork 26
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
I don't think MultiByteToWideChar
and WideCharToMultiByte
need to add 1 to num_bytes
#111
Comments
I'm aware of the docs, but since these functions are at the core of the library, I was just over precautious of that extra null room... and that's because Win32 functions don't follow a standard: some of them include null in the computation, while others don't. So I chose not to take any chances. Also: what happens if the input buffer doesn't have a terminating null? |
IIUC, the null behavior here is very well documented in the docs I copied in above. I definitely understand that the Windows API is the wild west, but I do think the behavior is stable here if I am reading it correctly! FWIW, we've had to use these functions quite a bit when working on Windows with R and we've never had issues with needing the extra +1 Our main IDE, RStudio, also uses them this way: The C++ library,
That is also well documented in what i copied in from above
And in fact that is often the case for the RStudio IDE. On Windows we can get a crazy string like
(Yes, it is crazy) We end up having to take a string slice to extract out the |
Very interesting stuff, thank you. I removed that |
I really appreciate that! Thanks! |
I believe these
+1
additions tonum_bytes
are not required, and are actually resulting in strings that are too long:https://rodrigocfd.github.io/winsafe/src/winsafe/kernel/funcs.rs.html#1483
https://rodrigocfd.github.io/winsafe/src/winsafe/kernel/funcs.rs.html#1725
MultiByteToWideChar()
takes amulti_byte_str: &[u8]
and gets its size withmulti_byte_str.len()
WideCharToMultiByte()
takes awide_char_str: &[u16]
and gets its size withwide_char_str.len()
So for the inputs to those functions, the nul terminator should already be included in the length if there is one.
And then for the output, I'm looking at:
https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar#parameters
https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte#parameters
For MultiByteToWideChar:
For cbMultiByte (only included the "positive integer" case):
For cchWideChar:
For WideCharToMultiByte:
For cchWideChar (only included the "positive integer" case):
For cbMultiByte:
This documentation makes me think that the size returned from these functions when passing a null buffer already includes the nul terminator if one is present in the string, so adding 1 ends up adding extra space.
Indeed that seems to be the case in my testing as well. i.e. roundtripping an
x
containing something like"hi there"
through this helper will result in a string with 2 extra\0
on the end. I manually removed the+1
and things start looking as I'd expect.The text was updated successfully, but these errors were encountered: