After upgrade of CFamily in 6.33 in SonarCloud, new bugs on S1763 detected


We use Sonar cloud in our company to scan our C++ code, and we use Quality Gate to allow merges and to avoid to introduce new bugs.

After upgrade from 6.32 to 6.33 of the CFamily, 16 new bugs were notified on our new code; all those bugs are from the same rule (S1763), it appears at the same time as upgrade and with the exact same date of appearance.

So we were wondering :
is there any new way of detecting S1763 bugs on this release? (I didn’t find anything about it on the release note : Release Notes - SonarSource

Is it normal that those bugs appear in the field “New code” while thoses bugs are not due to new development?

Thank for your support,

Hello @AlexJulita, and welcome!

Indeed, we did not work on S1763 lately, moreover, this rule comes directly from a Clang built-in check, yet we did not change the Clang version between 6.32 and 6.33.

Can you give a short example of the dead code that was not detected by 6.32 and is detected by 6.33?

Feel free to generate a reproducer file, which helps us precisely capture the run environment (click to see).

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 source file .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.

Thank you for your quick answer, here is an example (in the screen); while(0)

Also, we’ve checked if there were some #ifdef or something like this that changed recently and that would not allow scan but we didn’t find anything (+ bugs are in lot of files).

After that there are also errors on multiple files.
I will try to use the reproducer files, i’ve never use it and since we use SonarCloud only with our CI I don’t know if it will be easy ! (+ I need to be sure that I won’t leak some protected files…)

I am going to need a reproducer to investigate this. I tried to reproduce your issue on this short code snippet based on your screenshot

void foo() {
  int confiancePasseNplus1Max = 18;
  while (0) {

However, my build of 6.32 detected the dead code there.
I’ll write you a message to get the reproducer privately.

I have received the reproducer file, and ran it with both versions: 6.32 and 6.33.
First of all, the analyzer threw the following errors:

LLVM ERROR: option not found: S1541.maximumFunctionComplexityThreshold
LLVM ERROR: option not found: S2304.format
LLVM ERROR: option not found: S1912.nonReentrantFunctionList
LLVM ERROR: option not found: S924.maxNumberOfTerminationStatements

That is suspicious, because, when generating the reproducer you must’ve seen one of these errors and gotten 0 reported issues.

I temporarily provided default values for these 4 missing options just to check whether there is indeed any difference, but I found none.

The reports for both versions 6.33 and 6.32 are identical and contain 5264 messages.

Are you sure you’ve generated a reproducer in the same circumstances in which you observe the differences in the bug counts?

Perhaps, you could generate two reproducer files: one for the run with 6.32 and one for the run with 6.33, this way I can also check that the runs for the two versions are identical (same environment, same compiler args, etc.)?


We use SonarCloud so I can’t run with 6.32 and 6.33 and I’m dependant of the versions used by SonarLint (This is how I generated reproducer file)

This is the bug that has been detected started 6.33 :

If we can’t find out if for real the bug is from the upgrade of the CFamily plugin or from a change from us that would impact 16 files then it is not a big deal, even if I would really like to know the end of the story …

Thank you for your help !

If you think you’ve done everything you could then let’s close this subject

Best regards

I’ve run 6.32 build on

#include <string>
using UA_Int32 = int;
class ClsOPCTools {
  static std::string TypeToString(UA_Int32 type, bool modeTiret);
std::string ClsOPCTools::TypeToString(UA_Int32 type, bool modeTiret)
  switch (type)
      // inca
    case 0:
        return modeTiret ? "--INCA---" : "INCA";
      case 1:
        return modeTiret ? "--HUB---" : "HUB";
    case 2:
        return "CAM-TIAMA";
    case 3:
        return modeTiret ? "-CAM-POL-" : "CAM-POL";
    case 4:
        return "CAM-CDOS3";
    case 5:
        return modeTiret ? "-SOURCE--" : "SOURCE";
      return "ERREUR_TYPE";

And it did report S1763 on the last break; statement;

So, as suggested, I’ll close the topic for now. Feel free to come back if you come across a minimal source file that demonstrates the difference, maybe we will be able to reproduce it there.

Ok then !

Thank you Arseniy for spending time with me on this subject, and sorry that we didn’t reproduce …

See you maybe on other topic !

Have a nice day,

Best regards,


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.