Using most recent sonar/build-wrapper executables in a linux (el7) environment.
I’m wondering if there are any configuration options to either sonar or the build wrapper to control how the analysis is performed in a C project.
Currently I am scanning a single C internal library (mylib.a). Sonar “incorrectly” flags multiple issues like resource leaks because the library contains Init() functions which allocate and Destroy() function which free, but they are obviously never called because this is the library definition, not the full usage of the library.
Is there anyway to get sonar or the build-wrapper to detect these issues? Many of our functions are defined with the malloc attribute so sonar could see that the returned value is not expected to be freed in the same function.
Also, when I finally do scan the project that uses this library (Project), would it be better to scan Project individually or should I put both Project and mylib in a new directory and scan them both as a single new sonar project?
Can I ask what version of SonarQube and what version of the CFamily Code Quality and Security you are using? (In SQ, go to administration -> Marketplace -> Installed.
We try to cover the use case of a library as much as we can.
If some issues are false positives:
you can resolve these issues in SQ as “false positive” or as “won’t fix”
you can also report them to us. We are always happy to make our analyzers more accurate.
About detecting functions with the malloc attribute, I cannot see what false positive we would raise on that. Could you show me a very minimal example please?
Putting both the library and your project in the same Sonar project would bring a minimal gain as we do have only a few project level rules. They would not help in the context you are describing.
Thanks, Geoffray, I will see if I can come with more concrete examples.
As far as project/library structuring. Are you saying that if I have an app project which uses my own custom library, I should set this up in sonar as two independent projects? One that scans “app” and another that scans “library”?
What I meant is that analyzing both projects at the same time will not bring significant improvements in most cases.
Whatever the structuring you are using for your analyze now, I cannot see any reason to recommend to change it.
Here is an example of a false positive in library code:
static void begin_logging(LOG *log) {
log->fp = fopen(“logfile.log”, “a”);
}
static void end_logging(LOG *log) {
if (log && log->fp) fclose(log->fp);
}
Sonar is reporting “Opened file never closed”. I get why it’s reporting that, I’m just wondering if there’s a way to tell sonar to ignore this rule in this specific case.
I realize I can ignore blocks in source with a regex, but I’m not sure ignoring the fopen is a good idea. I also know I can mark as a false positive, but that could be a ton of issues I need to go through and inspect to be sure they are this kind of false issue.
Thanks for reporting that example. It seems you are hitting a false positive in the implementation of the rule. I created a ticket for that https://jira.sonarsource.com/browse/CPP-2554
You can follow any progress on this.
Because it will require quite some work, please do not expect this one to be fixed very soon.
I would recommend 2 options
You just mark this(these) issue(s) as won’t fix (or even false positive) in SonarQube with an explanation.