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.
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
[OSX] HybridGlobalization implement compare native function #85965
[OSX] HybridGlobalization implement compare native function #85965
Changes from 3 commits
5406aef
3494765
a2bd6b1
f84b02a
28f7699
ea9094b
461f926
3b7a33a
4e4fb08
cf1e1c7
ff743ec
4c78a3b
d558895
f31fb4c
b683bce
73fa470
4ce304a
e53aa0c
c316a26
199c27e
b0cbfac
b34d0a2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
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.
Migrating comment
Re: passing in string lengths, could we use something like initWithUTF8String or is there a chance that lpStr1's length is less than cwStr1Length? Just not sure why we need to pass in string lengths.
Ah looking into it more, it seems like
lpStr1
andlpStr2
will not be null terminated so we cannot useinitWithUTF8String
, it would've been nice to not have to pass extra parameters.Given that
GlobalizationNative_CompareStringNative
isStringMarshalled
withUTF8
, it feels like there would be problems casting toconst unichar *
as that isUTF16
, and a character represented in UTF8 might have a completely different representation in UTF16 that wouldn't align.Are there any test cases that mightve failed because of a string marshalled into UTF8 is different in its UTF16 representation?
Maybe we should be using
initWithBytes:length:encoding
?[NSString initWithBytes: lpStr1 length: cwStr1Length encoding: NSUTF8StringEncoding]
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.
Tried with
initWithBytes:length:encoding?
[NSString initWithBytes: lpStr1 length: cwStr1Length encoding: NSUTF8StringEncoding]
It can't convert properly from char* C# to objective C string , result is wrong. Thanks for pointing out UTF16 , will match it in C# and C and see how test cases will behave.
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.
Do you happen to know what the bytes passed to
pString1
inInterop.Globalization.CompareStringNative(m_name, m_name.Length, pString1, string1.Length, pString2, string2.Length, options);
look like and what the bytes inlpStr1
look like here when sticking withStringMarshalling.UTF8
?Are
NSUTF8StringEncoding
and theStringMarshalling.UTF8
differnt? I'm curious as to why it fails to create the correct string.I'm not sure what the full repercussions of using UTF16 if UTF8 is the default for OSX and for all other interop on OSX, we have been using UTF8.
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.
As for bytes I will check. But changing from
StringMarshaling.UTF8
toStringMarshaling.UTF16
didn't affect test cases.Currently in Interop.Collation.cs there are functions using
UTF8
and some of themUTF16
. The ones that passchar*
are usingStringMarshaling.UTF16
but not sure if this is the reason https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Interop.Collation.cs.In
OSX
https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Interop.Locale.OSX.cs so far onlyUTF8
is used, but also there is no case of passingchar*
.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.
I looked a little bit for the differences and it depends what are we passing from C# to C. In some functions we pass string, in others char*. When we need to pass char*, as char keyword occupies 2 bytes (16 bits) in the memory => UTF16 is the choice. But in my previous implementations I was only passing string (cultureName) so I chose to use StringMarshalling.Utf8 https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Interop.Locale.OSX.cs#L10
@steveisok could you please verify if this looks correct?