C++ fully specialized templates seen as variable

  • 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:

CPP file:

template<>
void EncodeBasicAsn1Type<ENAsn1DerTagTypes::E_BitString>()
{
  DoSomething();
}

Header file:

template<ENAsn1DerTagTypes tagType> void EncodeBasicAsn1Type();
template<> void EncodeBasicAsn1Type<ENAsn1DerTagTypes::E_BitString>();

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.

Hello @colin1993,

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.

Thanks,

@colin1993, any update on this? Were you able to generate the reproducer?

Hi @Abbas_Sabra

Sorry it took so long, but I know have a reproducer file and would like to share it with you in a private message - just to be sure.

Thanks.

@colin1993,
I sent you a PM.
Thanks,

Hi @colin1993,

Is the issue raised on the header or source file?

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?

Thanks,

Hi @Abbas_Sabra

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:


Hi @colin1993,

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?

Thanks,

Hi @Abbas_Sabra

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,
Colin