-
Notifications
You must be signed in to change notification settings - Fork 468
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
Add CA2022: Avoid inexact read with 'Stream.Read' #7208
Conversation
This analyzer detects calls to 'Stream.Read' or 'Stream.ReadAsync' that do not check the return value. These methods may return fewer bytes than requested, resulting in unreliable code. The fixer will recommend replacing the call with 'Stream.ReadExactly' or 'Stream.ReadExactlyAsync', if available.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7208 +/- ##
========================================
Coverage 96.48% 96.48%
========================================
Files 1439 1442 +3
Lines 344369 345212 +843
Branches 11324 11345 +21
========================================
+ Hits 332259 333081 +822
- Misses 9244 9256 +12
- Partials 2866 2875 +9 |
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.
Thank you @mpidash, left a few comment, mostly for messages. Overall looks good 👍
src/NetAnalyzers/Core/Microsoft.NetCore.Analyzers/MicrosoftNetCoreAnalyzersResources.resx
Outdated
Show resolved
Hide resolved
src/NetAnalyzers/Core/Microsoft.NetCore.Analyzers/MicrosoftNetCoreAnalyzersResources.resx
Outdated
Show resolved
Hide resolved
src/NetAnalyzers/Core/Microsoft.NetCore.Analyzers/Runtime/AvoidUnreliableStreamRead.Fixer.cs
Outdated
Show resolved
Hide resolved
...NetAnalyzers/UnitTests/Microsoft.NetCore.Analyzers/Runtime/AvoidUnreliableStreamReadTests.cs
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.
Looks good to me, thank you @mpidash!
One of the CI legs somehow failed, might be one of the docs are not in sync that needs build with /pack
PTAL
Runtime findings in src looks legit, please let us know if you would like to put up a fix for them, and also set This better to be done before the merged code flows to runtime, as the analyzer warns by default it would fail the |
Thanks for the review!
I ran the pack task again locally and got no changes, but it seems like the CI ran successfully now.
I can prepare a MR tomorrow to fix the findings and enable the rule (and disable it for tests). |
Yeah, I hit the rerun button and now it is passed, gonna merge now
Great, thank you! |
{ | ||
var invocation = (IInvocationOperation)context.Operation; | ||
|
||
if (symbols.IsAnyStreamReadMethod(invocation.TargetMethod)) |
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.
Can we special-case MemoryStream and UnmanagedMemoryStream where if we can prove the target Stream is one of those we don't issue diagnostics? Those, in particular the former, are commonly used and we know they are actually safe for this usage; I'd like to avoid causing a lot of noise around them. While we don't necessarily document it's safe, we also don't need to cause folks to do a lot of work in response.
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.
Those, in particular the former, are commonly used and we know they are actually safe for this usage; I'd like to avoid causing a lot of noise around them. While we don't necessarily document it's safe, we also don't need to cause folks to do a lot of work in response.
Thanks, created an issue, FYI @mpidash as the analyzer warns by default we need to fix such breaking false positives ASAP, please let me know ASAP if you have no time for this. Thanks!
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.
I can take a look at this.
see dotnet/roslyn-analyzers#7208 Most of these could be safely ignored because of the following assert. As far as I can see, The SftpFileStream.Read() implementation guarentees that the specified number of bytes is read anyway.
* .NET 9: fix CA1872 see https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1872 * .NET 9: fix CA2022 see dotnet/roslyn-analyzers#7208 Most of these could be safely ignored because of the following assert. As far as I can see, The SftpFileStream.Read() implementation guarentees that the specified number of bytes is read anyway. --------- Co-authored-by: Rob Hague <rob.hague00@gmail.com>
* .NET 9: fix CA1872 see https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1872 * .NET 9: fix CA2022 see dotnet/roslyn-analyzers#7208 Most of these could be safely ignored because of the following assert. As far as I can see, The SftpFileStream.Read() implementation guarentees that the specified number of bytes is read anyway. --------- Co-authored-by: Rob Hague <rob.hague00@gmail.com>
Fixes dotnet/runtime#69159.
Category: Reliability
Severity: Warning
This analyzer detects calls to
Stream.Read
orStream.ReadAsync
that do not check the return value. These methods may return fewer bytes than requested, resulting in unreliable code.The fixer will recommend replacing the call with
Stream.ReadExactly
orStream.ReadExactlyAsync
, if available.All findings look legit, mostly calls in test code, although there are a few hits in non-test code in
dotnet/runtime
:I've also added all findings from
dotnet/roslyn
,dotnet/runtime
anddotnet/aspnetcore
(no warnings found indotnet/roslyn-analyzer
:roslyn.txt
runtime.txt
aspnetcore.txt