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