-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Big-endian fix: GUID handling #49813
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
@@ -77,6 +77,24 @@ public static unsafe BlobContentId FromHash(byte[] hashCode) | |||
guidPtr[7] = (byte)((guidPtr[7] & 0x0f) | (4 << 4)); | |||
guidPtr[8] = (byte)((guidPtr[8] & 0x3f) | (2 << 6)); | |||
|
|||
// the code above assumed the host is little-endian; if this is not the case, |
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.
Would it be better to just construct the Guid using Guid (int a, short b, short c, byte d, byte e, byte f, byte g, byte h, byte i, byte j, byte k)
constructor instead of all the unsafe code and swapping bytes?
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.
Hmm, I initially tried to use a Guid constructor :-) The first thing I tried was the Guid (ReadOnlySpan<byte>)
constructor, which failed since the file is apparently also compiled against frameworks where spans are not available. Then I tried the Guid (byte[])
constructor, which worked, but I was told this would be an unacceptable performance regression due to the extra allocation ... That's when I went back to this solution that leaves the LE code path unaffected.
I can certainly try the separate-element constructor you point out, if that would be an acceptable change on the LE path.
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 think the separate-element constructor would be acceptable for both LE and BE paths here.
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.
Patch updated accordingly.
* Fix Utf8Formatter.Guid on big-endian systems (first three fields are stored in native byte order, not always little-endian) * Use Guid constructor in BlobContentId.FromHash to remove endian-dependent code accessing the structure directly
src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/BlobContentId.cs
Show resolved
Hide resolved
src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/BlobContentId.cs
Show resolved
Hide resolved
Hello @jkotas! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Fix Utf8Formatter.Guid on big-endian systems
(first three fields are stored in native byte order, not always
little-endian)
Fix low-level Guid structure access in BlobContentId.FromHash
(byte-swap first three fields on big-endian platforms)