Different issues shown by SonarQube and SonarLint

SonarQube for IDE Eclipse
1

Hi,

I know a similar issue raised two years ago, but I assume it is not the same problem only the same effect

My system is

  • Operating system: Windows 10
  • SonarLint plugin version: 10.2.0.81875
  • Programming language you’re coding in: C
  • Is connected mode used: Yes
    • Connected to SonarCloud or SonarQube (and which version): SonarQube 9.9.1

I’ve bound already my project to the project hosted on SonarQube, but the issues, which are shown by Sonar Lint differs in several ways— some issues, which are shown by SonarQube are not shown, some issues will be shown which are not shown by SonarQube and some Issues are shown with different values

Issues from SonarQube, not shown in SonarLint:

  • Redundant pairs of parentheses should be removed (c:S1110)
  • Implicit casts should not lower precision (c:S5276)
  • Tests of non-Boolean values against zero should be explicit (c:S883)
  • Unused function parameters should be removed (c:S1172)
  • Bitwise operators should not be applied to signed operands (c:S874)
  • Boolean operations should not have numeric operands, and vice versa (c:S867)
  • Braces should be used to indicate and match the structure in the non-zero initialization of arrays and structures (c:S835)
  • Empty “case” clauses that fall through to the “default” should be omitted (c:S3458)
  • Pointer and reference local variables should be “const” if the corresponding object is not modified (c:S5350)
  • Signed and unsigned types should not be mixed in expressions (c:S845)
  • Cyclomatic Complexity of functions should not be too high (c:S1541)
  • Files should not be too complex (c:S1908)
  • Loop variables should be declared in the minimal possible scope (c:S5955)
  • Magic numbers should not be used (c:S109)
  • Redundant casts should not be used (c:S1905)
  • The prefix increment/decrement form should be used (c:S1705)
  • Two branches in a conditional structure should not have exactly the same implementation (c:S1871)
  • Unused assignments should be removed (c:S1854)

Issues from SonarLint, not shown in SonarQube

  • a parse error because stdbool.h wasn’t found
  • “switch” statement should have at least 3 “case” clauses
    Remark: This issue is shown for switch statements with more than two case clauses

Issues with different values

  • Files should not be too complex (c:S1908) → different values: SonarLint 130, SonarQube 195
  • Pointer and reference parameters should be “const” if the corresponding object is not modified (c:S995) → different functions

I wonder why this can be happen because, as written, the project in eclipse is connected to SonarQube ans I assume the issues will be retrien by SonarLint via this connection. Is there something special to configure, e…g. in sonar-project.properties?

2

Hi,

Off-hand it sounds like a different (presumably older) version of the code was last analyzed by SonarQube versus what’s loaded in your IDE.

I’m stumbling a bit on this typo, but I guess you’re saying you expect SonarQube to be updated from SonarLint?

That’s just not how it works. Assuming I’m right about the code version difference between the two, can you commit/push your changes and check again after the pipeline runs?

 
Thx,
Ann

3

That was my first thought too, but after solving most of the issues displayed by SonarQube in several iterations, the issues displayed only by SonarLint have not changed. Furthermore, it seems that the issues shown only by SonarLint are not plausible. E.g. SonarLint shows in the code

...
  IOLM_CONFIG_MANAGER_RSC_T* ptConfigManagerRsc;

  for (uint8_t  bPort = 0; bPort < g_tIOLMStackRsc.bActChanNum; ++bPort)
  {
    ptConfigManagerRsc = &g_atConfigManagerRsc[bPort];

    /* Initialize Configuration Manager resources */
    memset(ptConfigManagerRsc, 0x00, sizeof(g_atConfigManagerRsc[bPort]));
    ptConfigManagerRsc->bPort = bPort;
...

the issue

Make the type of this variable a pointer-to-const. The current type of “ptConfigManagerRsc” is “struct IOLM_CONFIG_MANAGER_RSC_Ttag *”.

which actually cannot be correct, since neither ptConfigManagerRsc has a constant value nor its members

Sorry for the typo: I think, SonarLint retrieves the issues from SonarQube via the connection between my IDE and SonarQube. Is there information that can help me to figure out exactly how SonarLint and SonarQube work together?

Regards,
Ralf

5

Hi Ralf,

For C, SonarLint would only be retrieving Security Hotspots. All other issues would be detected by running analysis locally.

Let me ask: Are you making this comparison file-by-file as you work in your project, or are you trying to pull a list of issues in SonarLint for some kind of audit against SonarQube?

 
Thx,
Ann

7

Hi Ann,

I do this comparison while I work file-by-file because our company has bought the developer version of SonarQube and I try to find the best way for me and my colleagues to work with it.

In the Developing with Sonar chapter, I saw that SonarLint is useful for the developer side to give instant feedback in my IDE while writing code to find and fix issues before a commit, which would make my job easier. But since SonarLint shows me issues that were not collected by SonarQube or are wrong, it will not help me improve the quality of my code.

Regards,
Ralf

9

Hi Ralf,

Thanks for the detail. I’m not sure what’s going on here, so I’ve flagged this for more expert eyes.

 
Ann

11

Hi @Ralf_Ebert,

thanks for reaching out. Would you please provide me with the logs when you analyze one file? So when you open the file, await the analysis, then clear the logs (there is a context menu option) then make a simple change and await the analysis.
These logs I need.

I’m not that familiar with C/C++ development but the logs will state all the rules that are not present in SonarLint. Some are not present as they’re too complex to be computed in the IDE (e.g. cross-file issues), maybe there is an issue with the compiler flags that are handed over to SonarLint.
The logs will contain some answers to that.
Is auto-build enabled in Eclipse? For some rules we require the compiled code.

Best,
Tobias

12

Hi Tobias,

I’ve uploaded three files:

Regards,
Ralf

13

Hi @Ralf_Ebert,

thanks for the quick response. I’ve checked the logs and cleaned them a bit.

Truncated-SonarLint-Console-logs.log (74.3 KB)

I flag this for the C/C++ analyzer developer to investigate together with you as my C/C++ proficiency sadly ends here.

Thank you!
Best,
Tobias

17

Hi @Ralf_Ebert and thanks for sharing the problem with us,

The CFamily analyzer requires information from the build to analyze C and C++ files correctly. In SonarQube (or SonarCloud), this is usually achieved by extracting this information from the build using build-wrapper and passing the generated file to the scanner using the property sonar.cfamily.build-wrapper-output, see the docs here.

In SonarLint however, we don’t require a full build before invoking an analysis. Instead, this information is queried from the IDE. This means that the CFamily analyzer is able to provide an accurate analysis only when the IDE is configured on your project properly.

From the following symptoms, I would guess that the information retrieved from the IDE didn’t help the analyzer fully understand the code:

This most likely indicates that the include directories recognized by the IDE are inaccurate.

This is most likely a consequence of the analyzer not being able to recognize all the constructs in the file using the SonarLint configuration, reporting less complexity as a result.

I would suggest checking your project configuration in Eclipse. Are you able to build your project in the IDE? Is the missing file stdbool.h resolvable in the IDE? While tracking down this kind of problems, you can keep the S2260 rule enabled. This can show the parsing errors encountered by the analyzer, and can help identify the configuration issue behind it.

I hope this helps,

Best regards,
Michael

1 Like