The assumption about the incorrect operation of the code verification system

Good afternoon. Our company uses the SonarCloud service on a paid basis. We would like to ask you for help to understand. At this point, the checking system throws an error, while the previous line of code (checking for a non-null pointer) passes the check. We believe that this error is possible due to incorrect operation of the code verification system. Link to the place in the code: https://sonarcloud.io/project/issues?resolved=false&sinceLeakPeriod=true&types=BUG&id=brighteye_MEScontrol.net-Standard&open=AYOqoa1UHTL1pBw4toj-

Hi,

Welcome to the community!

That seems to be a private project. Can you provide the details here in this thread?

I guess you’re asking about an issue that’s raised on your code that you think is a false positive?

Can you provide either the snippet of code or a contained reproducer? And please be explicit about what language it is. Sometimes these things are obvious, but C-ish languages look remarkably alike sometimes.

 
Ann

Thankfull to you!

Yes, you are right.

Of course.
This is C# language.
This part of code on the screenshot, that attached to the letter.
Uploading: image.png…
Uploading: Безымянный.jpg…

I also sent a code listing

private Expression InnerGetFilterExpression(OperandProperty criteriaProperty, CriteriaOperator criteriaOperator, FilterOperator filterOperator)
{
        var criteriaValue = criteriaOperator as OperandValue;
if (criteriaValue!=null) {
if (criteriaProperty.PropertyName==KeyColumnName && criteriaValue.Value is MesKey)

      >  'criteriaValue' is null on at least one execution path.[Why is this an issue?] 
>           (https://sonarcloud.io/project/issues)
>           * Bug * Major * Open * 10min effort * No tags+


return GetMesKeyFilterExpression((MesKey)criteriaValue.Value);
}

Hi,

Thanks for the code snippet. Unfortunately, the screenshot uploads didn’t finalize before you submitted, but the code sample helps. I’ll flag this for the language experts.

 
Ann

Thank you very much, Ann.

Hello Valery,

this is a known issue and we are going to fix this in one of our next releases. You can track our work on this in this issue: S2259 FP: Lifted operator results in null value in value type comparison · Issue #4250 · SonarSource/sonar-dotnet · GitHub For the moment I would suggest marking this issue in SonarCloud as “Won’t fix”.

Best, Martin

1 Like

Hello Martin,
Thaks a lot for your replay, looking forward to the next release.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Hello.
I nead to open this topic again to learn some details, but it was closed after time.

This is part of our code, that i posted earlier:

private Expression InnerGetFilterExpression(OperandProperty criteriaProperty, CriteriaOperator criteriaOperator, FilterOperator filterOperator)
{
        var criteriaValue = criteriaOperator as OperandValue;
if (criteriaValue!=null) {
if (criteriaProperty.PropertyName==KeyColumnName && criteriaValue.Value is MesKey)

      >  'criteriaValue' is null on at least one execution path.[Why is this an issue?] 
>           (https://sonarcloud.io/project/issues)
>           * Bug * Major * Open * 10min effort * No tags+


return GetMesKeyFilterExpression((MesKey)criteriaValue.Value);
}

This is link to closed post: The assumption about the incorrect operation of the code verification system

I wanted to ask Martin for some information about our problem.

Martin, hello again.

We analyzed these two cases (false positive diagnostic in our codebase and false positive diagnostic in your issue) and we think they are not similar.
The diagnostic in their issue has more specific details and it is more complicated case. In their case they used lifted operators including implicitly during condition check. And then, after attempt to return some value, it leads to a false diagnostic.
But our case is much easier - we have only null-check for the local variable(like “if (a != null)”) and only dereferencing this checked variable into the branch of this if (like “a.DoSmth();”). And we have the same false positive diagnostics for a lot of easy cases like this.
Are sure your new release helps as to solve this problem??

Hello @Valery - the ticket Martin gave is still open, it hasn’t been fixed yet

Hello Andrei.
Above, I described our specifics of the occurrence of errors.
Tell please, will your fix work for them?