[release/0.8] Backport 'Bugfix for UnicodeString constructor' #1306
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This cherry-picks two changes that fixed bugs when unpacking images that contained non-ascii characters.
0afb0c9
587be85
The existing UnicodeString constructor creates a unicode string object by taking the
length of a given GO string. This works fine for ASCII strings but fails when the input
string contains non ASCII characters. This change fixes it.
Description:
In the earlier version of NewUnicodeString the length would be set to the number of bytes in the string than the number of runes in the string. If the input string of 3 runes had one non-ascii character (i.e a character that would take 2 bytes to encode in UTF=8) the value of length would be 4 and the UnicodeString.Length & UnicodeString.MaximumLength would be set to 8. However, the buffer returned by UTF16FromString would include only 3 uint16s which is 6 valid bytes. So the generated UnicodeString would end up with garbage bytes at the end. Moreover the win32 UNICODE_STRING expects that the Length field should not include the terminating null character.
The above change fixes both of these issues by using the length returned by UTF16FromString .
The test was failing because the image that the test imports has an image that has a file with non-ASCII character in the name. So during the image extraction the safefile.OpenRelative call tries to convert that path to the UnicodeString to pass it to NtCreateFile and NtCreateFile fails with "The filename, directory name, or volume label syntax is incorrect".