Only critical issues found for Header files in short-lived branch

Hi,

it seems that for some reason only Critical issues are detected/shown in our Header files, this means no Blocker, minor, … -level issues though they properly appear in the .c files.
Since at least the critical issues are found in the .h files i assume that these files are analyzed so the build wrapper output should be ok.
The scanner output also contains a line stating that the header file is analyzed:

11:04:31.798 DEBUG: ‘sources\Common_Func\Com_Math.h’ indexed with language ‘c’

Screenshot of issue in .c file
issue_in_c

Similar line in .h file does not trigger an issue.

Must-share information (formatted with Markdown):

  • SonarQube Enterprise Edition Version 7.3 (build 15553), SonarQube Scanner 3.2.0.1227,
  • having issues of all severity-levels displayed for new code in short-lived branches
  • see above

thx,
Peter

1 Like

Hello Peter,

There is no mechanism that only issues of a certain level are reported in a branch analysis. So let me try to understand better what you see. Could you please tell me, for each of the following statement, if it is correct:

  • You are using SonarCFamily, not another plugin
  • You are using the build wrapper to configure the analysis
  • The same code triggers an issue if it is in a C file, not if it is in a header file
  • If you analyze the code in the master branch, the issue is reported
  • In the same header file, you can see that some other issues are reported
  • The issue is not a previously existing one, it is one that is introduced by a change in the header file in the branch that you analyze.

Additionally, could you provide us with the analysis logs, as well as with the build wrapper files?

Thank you,

thank you for taking care,

  • You are using SonarCFamily, not another plugin

yes, it is also listed in the SonarScanner output:

15:00:29.438 INFO: Load/download plugins (done) | time=166ms
15:00:29.566 DEBUG: Plugins:

15:00:29.567 DEBUG: * SonarCFamily 5.1.1.10386 (cpp)

  • You are using the build wrapper to configure the analysis

yes, this is the executed command:
C:\Tools\sonar-build-wrapper-win-x86\build-wrapper-win-x86-64.exe --out-dir sonar_bw_output conan build --build-folder build_host .

  • The same code triggers an issue if it is in a C file, not if it is in a header file

yes, its even the header file included (C-wise) in the .c file:

  • If you analyze the code in the master branch, the issue is reported

i re-checked this and this type of issue is also not reported in the develop (long-lived) branch so i added some more code to trigger different kinds of issues and it seems that just rules checking comments in the code are not triggering issues.
E.g. the rules c:S2323, c:C99CommentUsage and c:S1103 are not triggering issues in header files but c:Union and c:PPUndefUsage do.
So my question/issue has changed to: whether/why comment-related rules are not applied to header files?

  • In the same header file, you can see that some other issues are reported

yes, i tried some non-comment-related rule, they all trigger issues.

  • The issue is not a previously existing one, it is one that is introduced by a change in the header file in the branch that you analyze.

yes

Additionally, could you provide us with the analysis logs, as well as with the build wrapper files?

i would need to make sure these logs do not contain any confidential information.
I assume that due to the new insights stated above the logsmay not be relevant anymore, otherwise i will prepare the logs if needed.

thx,
Peter

The answer to this question is yes. This is a limitation of the current version.

However, you might be happy to know that this limitation has been lifted and that, starting in the upcoming version 6.0 of the SonarCFamily plug-in, comment related issues are reported in all files, not only the main file.

Thanks for the info, good to hear that this is being addressed. Is that limitation documented somewhere so i know what to look for in e.g. future release notes?

No, it is not, but I already added a note in our draft release notes to mention this change.