SonarQube incorrectly identifying cpp:S5817: this function should be declared const

[jrl2n4 (John M)]

I’m using SonarQube to examine a pre-existing codebase. It’s primarily C++.

SonarQube is generating a ton of false positives for cpp:S5817: member functions that don’t mutate their objects should be declared “const”.

void callbackVehicleId(const std_msgs::UInt64::ConstPtr& msg)
{
  vehicle_id_ = msg->data;
}

Roughly 30% of the smells being detected are something like this, which translates to hundreds of false positives. 1 - 10 line functions that trivially mutate their calling objects. In this specific case, vehicle_id_ is a private non-const member of the class, nothing fancy. The other 70% of the smells appear to correctly identify potentially const functions.

Is there some kind of misunderstanding of the rule being applied, or some scanning configuration that I should check on to get useful results out of this rule?

• SonarQube Enterprise Edition Version 8.9.8 (build 54436)

[marco.b]

Hello @jrl2n4, and welcome to our community!

We released two patch releases for the LTS since 8.9.8. Could you upgrade to at least 8.9.10 so we can rule out issues that were already solved? Thanks.

If the issue persists after upgrading, could you look at the analysis log? I suspect some parsing errors impact the analysis quality. See, for example, here for some tips: https://rules.sonarsource.com/cpp/RSPEC-2260.

HTH

[jrl2n4 (John M)]

Thank you for the quick reply, @marco.b !

Just finished upgrading and re-ran the analysis, it came back with the exact same amount of issues. My next step was going to be to check the logs and I see five log files being generated: access.log, ce.log, es.log, sonar.log, and web.log. Could you clarify which of these logs would have the analysis logs and give me a hit what I should be looking for?

[ganncamp (G Ann Campbell)]

Hi,

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
HTH,
Ann

[jrl2n4 (John M)]

Ah, understood, thank you for the tip.

The logs pointed me towards the likely real issue, that all of my header files generated from .msg’s in ROS weren’t found by SonarQube. I opened a new post with this more specific issue: SonarQube support for .h files machine generated by ROS during compilation

Thank you for the hint!