I use C++ to test C code. This leads to a myriad of false positives when C++ rules are applied to C code header files — to the point where it has become more than a slight annoyance. I’ve had to turn off several rules just to make things bearable.
So I was thinking: all the required information is available. I understand Sonar works with compilation units, not header files — however, it should still be possible to filter the issues after scanning and weed out all the false hits for C++ rules in C header files. I don’t see any scenario where this would not make sense (unless people put C++ code in C header files…)
In the meantime, I’m considering setting up a weekly pipeline run in Azure to automate this via the REST API, but I’m not sure I’ll be able to access all the necessary meta info.
Any thoughts?
Further info: I had posted about this topic a while back, which clarified several aspects, but the solution of running 2 separate scans (one for C, one for C++), just seems highly impractical.
In case it helps someone, I had some time last Sunday and wrote a little bash script that sets the corresponding issues to ‘false positive’ via the web API – worked like a charm for me in this test repo
It has an --all and a --pr <number> option to limit the scope. My current plan is to integrate this as a post-scan step in my Azure pipeline. But of course, having the Sonar Scanner filter nip these in the bud would be far more elegant
We had a discussion today. We were wondering whether the following solution would work in your situation. When a header file is included in both a C and C++ translation unit, then the C++ issues are filtered out. Would such a solution work in your situation?
We don’t want to change the behavior of there parameters since that could change the behavior for a larger part of our user-base.
Thanks for looking into this – (In my ‘real’ codebase) All my .h (C) header files are included in at least one C++ (test) and one C (production code) translation unit, so I does not seem the C++ issues are filtered out.
I just tried to add a C compilation unit in my example repo, but I didn’t help either (cf. these issues on sonarqube cloud)
As far as I understand, I’m not asking for a change in behaviour in the ‘suffix’ parameters - more like an automatic ‘culling’ of C++ issues that are marked in code in that is C header files (.h, or as per the suffix configuration). IMO, these issues are ‘false positives’, since there is no reason to apply C++ rules to C code.
I think you misunderstood what @mark.dewever asked you. We were not talking about the expected current behavior, but about a way we were thinking of modifying the analyser in order to solve your issue.
From your answer, I gather that all your C headers are included once from a C file, therefore we could use this criterion to classify them as C headers.
This would still be a blunt classification, because a header included from C can contain C++ code (inside a #ifdef directive), but it still looks like a possible solution. WDYT?
Hi @JolyLoic
Indeed I misunderstood - I thought the question has "are all your .h files included in both a .cpp and .c - thank you for making me aware.
When a header file is included in both a C and C++ translation unit, then the C++ issues are filtered out. Would such a solution work in your situation?
This sounds like it would work in my scenario, as long as ‘header file’ means .h. file. These can indeed contain C++ code, you are absolutely right. In my case, this happens only once in the entire codebase, for 3 static_asserts, otherwise my .h files are pure C code.
From your answer, I gather that all your C headers are included once from a C file, therefore we could use this criterion to classify them as C headers.
Yes, that seems correct to me. But didn’t I specify that already with sonar.c.file.suffixes=.c,.h?
I was under the impression that by setting sonar.[c,cpp].file.suffixes, I was telling/forcing the scanner: treat “.hpp as C++ and .h as C” and thereby forfeiting and mixes of the 2 languages in a single file.
I obviously don’t understand enough about the way the Sonar scanner works, so this might sound naïve – my thinking was:
the scanner works on compilation units after the preprocessor, so never ‘sees’ header files per se
after the scanner, there is some sort of ‘reporting’ that turns the scanner results into the web applications that lets me browse issues by filenames. Every issue (aggegrated from several compilation units) is associated with exactly one file.
Then for each .h file, cull all issues raised for cpp: rules. This is essentially what I’m doing with my web API script.
Of course, if you can ‘nip it in the bud’ at an earlier stage, that’s probably even better
I’m not familiar with all the uses of these suffixes, but for the main part of the analysis, they are mostly ignored, because they are not accurate enough. For the main analyzed file, if there is a compilation database, we rely on the information it contains, for included files, we rely on the main file.
Even if most of the rules run after preprocessing, some of the rules are computed before the preprocessor (rules about macros and include directives for instance). So our analyzer sees all the details.
This is mostly correct. The aggregation happens before this reporting.
We would not do it at this stage, but during the aggregation.
