False Negative for rule RSPEC-2674

Rules and Languages Report False-positive / False-negative...
1

Hi Team,

Sonarqube version 25.5
Lang: Java
SonarScanner version: 5.0.1.3006

The expected SonarQube bug appears not to be caught in the code below, even though it’s caught in a very similar code as seen in the screenshot. Any thoughts?

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
class BugExample {

    public void showBug() throws IOException {
        byte[] data = new byte[] {1, 2, 3};
        InputStream is = new ByteArrayInputStream(data);
        byte [] buffer = new byte[1000];
        int unusedVariable12345678 = is.read(buffer); 
    }
    public static void main(String[] args) {

        BugExample bugExample = new BugExample();

        try {
            bugExample.showBug();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

screenshot of code scan result

image
image1807×648 189 KB

4

Hi Engmscyorku,

Thanks for your post! I tried out the example you shared and it seems to be working as expected on my end:

  • S2674 isn’t reported, which makes sense because the result of read is assigned to a variable.
  • S1481 and S1854 are correctly detected, both pointing to the same issue of an assigned but unused variable.

If anything, the problem is that we generate two issue for the same problem of assigning to an unused variable.

Could you elaborate on why you think S2574 would be relevant or useful in this particular scenario? Do you think we should have 3 issues here or should we supress some of them?

5

Hi Tomasz,

Thank you for the detailed response.

Yes, S1481 and S1854 are valid in this case due to the unused variable. However, I do believe S2674 should still be raised in this scenario, so all 3 issues should be flagged, and here’s why:

  • My understanding is that the core purpose of S2674 is to ensure that the result of read() is validated by the developer. In this case, the result of read() is assigned to a variable without checking the return value, and this omission still leaves the code vulnerable to the intended bug.

I would expect S2674 to be flagged alongside S1481/S1854 because assigning the value isn’t equivalent to validating it. Additionally, SonarQube has shown the capability to report overlapping concerns, such as flagging both “Reliability” and “Maintainability” rules in similar cases.

Thanks again for the insights. Let me know your thoughts.

6

I created a ticket, SONARJAVA-5724, to capture this discussion.

If we find more problems with this rule, we can address them there together and redo the implementation. Personally, I’m hesitant to raise multiple issues on the same line since they all stem from a single problem.