-
Notifications
You must be signed in to change notification settings - Fork 5.3k
(MQ cleanup) Use BinaryPrimitives where possible #43474
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
Conversation
|
This seems like something that could be automated to catch the majority of cases. 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. |
src/libraries/Common/src/System/Net/SocketAddressPal.Windows.cs
Outdated
Show resolved
Hide resolved
| buffer[5] = (byte)0; | ||
| buffer[6] = (byte)0; | ||
| buffer[7] = (byte)0; | ||
| BinaryPrimitives.WriteUInt32LittleEndian(buffer.AsSpan(4), 0); |
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.
Endianness here wouldn't matter. But I guess it doesn't really matter perf-wise, especially on a little-endian arch.
src/libraries/System.Private.CoreLib/src/System/Resources/ResourceReader.cs
Outdated
Show resolved
Hide resolved
stephentoub
left a comment
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.
Nice. Thanks.
|
Oh, the joys of not having a working build environment and relying on CI. ;) |
|
Failing OSX leg is known issue #44037. |
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
BinaryPrimitivesinstead.Since
BinaryPrimitiveswasn'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:
BigEndianwhere I meant to writeLittleEndian(or vice versa).MemoryExtensions.Slice.NullReferenceExceptionor anIndexOutOfRangeException. The new code paths instead will result in anArgumentOutOfRangeException. 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.