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

(MQ cleanup) Use BinaryPrimitives where possible #43474

Merged
merged 6 commits into from
Oct 30, 2020

Conversation

GrabYourPitchforks
Copy link
Member

@GrabYourPitchforks GrabYourPitchforks commented Oct 15, 2020

This finds places in the code where we're reading data one byte at a time to build up a larger integer, and it replaces those patterns with calls to BinaryPrimitives instead.

Since BinaryPrimitives wasn't introduced until netcoreapp2.1, I didn't touch projects like System.Diagnostics.EventLog that target earlier runtimes. I also didn't touch existing netcoreapp2.1 projects if it would have meant adding a System.Memory package dependency where such direct dependency didn't previously exist. I also didn't touch the wasm-specific crypto code which was essentially a direct port from .NET Framework 4.x. That code's being deleted eventually anyway.

Risks:

  • I may have written BigEndian where I meant to write LittleEndian (or vice versa).
  • I may have passed the wrong parameters to MemoryExtensions.Slice.
  • If a previous data access would have failed due to an out-of-bounds exception, the original code path would have resulted in a NullReferenceException or an IndexOutOfRangeException. The new code paths instead will result in an ArgumentOutOfRangeException. I don't think anybody is relying on the old behavior because I believe every call site I touched is guarded with an explicit bounds check, but needs to be called out nonetheless.

@stephentoub
Copy link
Member

This seems like something that could be automated to catch the majority of cases. Did you consider an analyzer/fixer?

@GrabYourPitchforks
Copy link
Member Author

Did you consider an analyzer/fixer?

Only briefly. The big marks against spending time working on an analyzer are that: (a) there didn't seem to be an egregiously large number of occurrences; and (b) even within this PR there were a few different variations on this pattern.

buffer[5] = (byte)0;
buffer[6] = (byte)0;
buffer[7] = (byte)0;
BinaryPrimitives.WriteUInt32LittleEndian(buffer.AsSpan(4), 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Endianness here wouldn't matter. But I guess it doesn't really matter perf-wise, especially on a little-endian arch.

Copy link
Member

@stephentoub stephentoub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Thanks.

@GrabYourPitchforks GrabYourPitchforks marked this pull request as ready for review October 29, 2020 23:48
@GrabYourPitchforks
Copy link
Member Author

Oh, the joys of not having a working build environment and relying on CI. ;)

@GrabYourPitchforks
Copy link
Member Author

Failing OSX leg is known issue #44037.

@GrabYourPitchforks GrabYourPitchforks merged commit 04c5644 into dotnet:master Oct 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
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.

2 participants