-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
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
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
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:
BigEndian
where I meant to writeLittleEndian
(or vice versa).MemoryExtensions.Slice
.NullReferenceException
or 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.