Skip to content
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

Merged
merged 1 commit into from
Mar 19, 2021
Merged

Big-endian fix: GUID handling #49813

merged 1 commit into from
Mar 19, 2021

Conversation

uweigand
Copy link
Contributor

  • 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)

@dotnet-issue-labeler
Copy link

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,
Copy link
Member

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?

Copy link
Contributor Author

@uweigand uweigand Mar 18, 2021

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.

Copy link
Member

@jkotas jkotas Mar 18, 2021

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.

Copy link
Contributor Author

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
@ghost
Copy link

ghost commented Mar 18, 2021

Hello @jkotas!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@akoeplinger akoeplinger merged commit c373952 into dotnet:main Mar 19, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Apr 18, 2021
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants