[Xamarin.Android.Build.Tasks] make CA2022 an error #9282
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I was building Xamarin.Android.Build.Tasks and noticed some CA2022
warnings that scared me:
src\Xamarin.Android.Build.Tasks\Utilities\AssemblyCompression.cs(77,6):
warning CA2022: Avoid inexact read with 'System.IO.FileStream.Read(byte[], int, int)' (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2022)
src\Xamarin.Android.Build.Tasks\Utilities\MonoAndroidHelper.cs(186,8):
warning CA2022: Avoid inexact read with 'System.IO.FileStream.Read(byte[], int, int)' (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2022)
Some cases like this were actually ok:
byte[] publicKey = new byte[stream.Length];
stream.Read (publicKey, 0, publicKey.Length);
// ...
name.PublicKey = SigningHelper.GetPublicKey (publicKey);
Because it uses `stream.Length` for the `byte[]` size, we don't need
to use the return value of `Read()`.
Looking at another place, however:
sourceBytes = bytePool.Rent (checked((int)fi.Length));
// ...
fs.Read (sourceBytes, 0, (int)fi.Length);
// ...
destBytes = bytePool.Rent (LZ4Codec.MaximumOutputSize (sourceBytes.Length));
This actually is a bug, as it rents a `destBytes` array potentially a
bit larger than bytes read.
This made me think, we should make CA2022 an error and fix them all.
I also updated `MonoAndroidHelper.SizeAndContentFileComparer` to just
use the `Files.HashFile()` method. This is probably faster than the
previous code, anyway.
jonathanpeppers
commented
Sep 4, 2024
Comment on lines
354
to
+356
| using (Stream stream = typeof (GenerateResourceDesignerAssembly).Assembly.GetManifestResourceStream ("Resource.Designer.snk")) { | ||
| byte[] publicKey = new byte[stream.Length]; | ||
| stream.Read (publicKey, 0, publicKey.Length); | ||
| _ = stream.Read (publicKey, 0, publicKey.Length); |
There was a problem hiding this comment.
This one looks ok, so I just used the _ discard to silence the warning.
Comment on lines
-178
to
+180
| using (var f1 = File.OpenRead (x.FullName)) { | ||
| using (var f2 = File.OpenRead (y.FullName)) { | ||
| var b1 = new byte [0x1000]; | ||
| var b2 = new byte [0x1000]; | ||
| int total = 0; | ||
| while (total < x.Length) { | ||
| int size = f1.Read (b1, 0, b1.Length); | ||
| total += size; | ||
| f2.Read (b2, 0, b2.Length); | ||
| if (!b1.Take (size).SequenceEqual (b2.Take (size))) | ||
| return false; | ||
| } | ||
| } | ||
| } | ||
| return true; | ||
| string xHash = Files.HashFile (x.FullName); | ||
| string yHash = Files.HashFile (y.FullName); | ||
| return xHash == yHash; |
There was a problem hiding this comment.
This code should just use Files.HashFile() instead, it's probably faster and easier to read.
Comment on lines
-80
to
+83
| destBytes = bytePool.Rent (LZ4Codec.MaximumOutputSize (sourceBytes.Length)); | ||
| int encodedLength = LZ4Codec.Encode (sourceBytes, 0, checked((int)fi.Length), destBytes, 0, destBytes.Length, LZ4Level.L12_MAX); | ||
| destBytes = bytePool.Rent (LZ4Codec.MaximumOutputSize (bytesRead)); | ||
| int encodedLength = LZ4Codec.Encode (sourceBytes, 0, bytesRead, destBytes, 0, destBytes.Length, LZ4Level.L12_MAX); |
There was a problem hiding this comment.
So, I think this code previously was renting a larger destBytes byte array than needed. I think we probably had extra empty bytes at the end? Potentially garbage bytes, too?
jonathanpeppers
requested review from
grendello,
dellis1972 and
jonpryor
as code owners
grendello
approved these changes
Sep 4, 2024
|
There are some APK tests that failed with: But I don't think these changes could affect this, so going to merge. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was building Xamarin.Android.Build.Tasks and noticed some CA2022 warnings that scared me:
Some cases like this were actually ok:
Because it uses
stream.Lengthfor thebyte[]size, we don't need to use the return value ofRead().Looking at another place, however:
This actually is a bug, as it rents a
destBytesarray potentially a bit larger than bytes read.This made me think, we should make CA2022 an error and fix them all.
I also updated
MonoAndroidHelper.SizeAndContentFileComparerto just use theFiles.HashFile()method. This is probably faster than the previous code, anyway.