cpp:S5950 falsely triggered

Given a third-party API that returns a raw pointer to an object and which transfers ownership of the object to the caller

When I immediately construct an instance of std::unique_ptr to hold the raw pointer and delete it when the unique pointer goes out of scope

Then SonarQube triggers cpp:S5950 “Use std::make_unique to construct std::unique_ptr”

How? std::make_unique takes zero or more arguments and uses ‘new’ to construct an instance of the type, passing the supplied parameters to the constructor. In my case the object has already been ‘new’ed. I have no control over this.

The rule cpp:S5950 does not seem to understand that std::unique_ptr can be used to take ownership of existing heap-objects whose construction was not under the direct control of the instantiating code.

E.g.

const std::unique_ptr<const xxxxx_lpp::Velocity> velocity(pdu.get_const_data());

In this case the pdu class is part of a third-party library. The method get_const_data returns a raw pointer on which delete must be called when the caller has finished accessing the object.

Can cpp:S5950 be improved so that it is not triggered in cases like this?

Hey there!

Thanks for the report.

What flavor (Cloud? Server? IDE?) and, if relevant, what version of SonarQube are you using?

Hi,

We have Sonar installed on company servers.

Enterprise Edition v2025.4.2 (112048)

This issue is visible in JetBrains CLion using the SonarLint plugin, and also visible directly within the Sonar web UI.

Hi @jump-jet, and thanks for reaching out.

We have an internal ticket to improve this False Positive. I’ll bump it’s priority!

Cheers,
Marco

Ok, thanks.