Memory Leaks category and the Numeric Type mismatches in C++


Currently, we are using a Static scanner that runs our C, C++ codebase. We are experimenting with the SonarCloud product. Created a trial account and ran a static scan. We are quite impressed with the results.

However, we have noticed a couple of items:

  1. The number of memory leaks related issues reported are lesser. We went further added a memory leaked code and the scanner did not flag that piece of a code snippet as a memory leak.
  2. Type mismatch - (e.g converting int to unsigned) is not flagged.

Is there any difference between using SonarQube and SonarCloud?

Please let us know if there needs to be a separate rule that needs to be added. Except for these two issues we are quite pleased and this may be a deal-breaker for us.


Hello @vimalathithan,

Welcome to the community and glad you are liking our product.

This rule will definitely be available in the list of rules you can enable soon. We have already a ticket for it that is already in progress.

Are all the issues that you are manually introducing in the same function?
If yes follow carefully this post it will provide the explanation why your testing approach doesn’t’ reflect the accuracy of our analyzer and how splitting the memory leaks in a way that they can happen in real-life will lead to our analyzer detecting the issues.

If no, please provide a simple example that we don’t detect and I will be happy to help.

Hope this helps,

Thank you for your reply @Abbas_Sabra!

Thank you!

Yes, it is clear now. We will retest and let you know.

Additional questions:

  1. Can we manually add additional rules to the scanner for enterprise edition or cloud edition. Is it required or valuable to do so? Your thoughts.
  2. Is there any difference between an enterprise edition and a cloud edition on the number of rules?


By default, you are using the “Sonar way” Quality Profile. It is a good starting point. It includes the set of rules that we think are useful for most codebases. Now, of course, some codebases might want to have stricter/additional enforcement due to their nature. In that case, You can always extend “Sonar way” to enable the disabled rules that you like. That is totally up to you, you are a better judge since you have a better idea about the nature of your codebase.

When it comes to the number of rules, there no difference. It is just that SonarCloud gets the newly developed rules faster due to its continuous delivery approach.

let me know if you have further questions,

Thank you for the details! This is really helpful.

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