SonarQube Developer Edition - Version 9.6.1 (build 59531)
SonarScanner 4.6.0.2311
sonar-cfamily-plugin-6.36.0.52033
In our code-base, we have a cpp-file containing the implementation of a fully specialized template. It is also declared in the corresponding header file, but outside of a class. This is needed to be compatible to some compilers and targeting C++11. A snippet of the code is here:
For some reason, SonarQube seems to interpret these declarations and definitions as global variables and complains that they should be const. Do you need more information to track down, why these functions are interpreted as variables? The exact rule is cpp:S5421.
I need a reproducer file to be able to reproduce the issue.
to generate the reproducer file:
Search in the analysis log for the full path of the source file for which you want to create a reproducer (for instance, a file that contains a false-positive). You will have to use exactly this name (same case, / or \…)
Add the reproducer option to the scanner configuration:
sonar.cfamily.reproducer= “Full path to the .cpp”
Re-run the scanner to generate a file named sonar-cfamily.reproducer in the project folder.
Please share this file. If you think this file contains private information, let us know, and we’ll send you a private message that will allow you to send it privately.
I rerun the reproducer that you shared and S5421 is not raised while analyzing CFdamDerEncoder.cpp.
Can you share a screenshot of the raised issue to see if there is anything suspicious about it?
The weird thing is, we get (different) issues on both - the declaration in the header as well as the definition in the cpp file. We get the issue on following specializations:
CPP:
E_BitString
E_Integer
E_Octet_String
E_Utf8String
Header:
E_Integer
E_Octet_String
E_Utf8String
Hope that helps, it looks quite strange. Thanks!
See also the attached screenshots for (1) header and (2) cpp:
I had it another look. The reproducer that you shared doesn’t raise this S5421. That is weird since it includes all the information needed to replay the analysis.
I noticed something suspicious.
The reproducer is with 6.38.0.60268 and SonarQube 9.7.
While you said at the beginning:
SonarQube Developer Edition - Version 9.6.1 (build 59531)
sonar-cfamily-plugin-6.36.0.52033
Did you update the SQ version between facing the false-positive and the reproducer generation?
Do you still face the false-positives after the update?
Are you generating the reproducer with the analysis of the commit where you faced the false positives? or did the file changed since then?
a lot of questions.
We did update SQ in between facing the issue and generating the reproducer.
I already marked it as “false-positive”, so maybe it’s still in the database, but not detected anymore? If so, we can close this thread here and I’ll generate a reproducer the next time it happens, if it will ever happen again. If you really want to dig in I can try to generate a reproducer with the commit containing the change.
Thanks for your continuous effort in generating a reproducer. I think a lot of things have changed and not worth it that you spend more time on it. Let’s open a new thread when you face an issue after the update.