[cfe-dev] [Static Analyzer] Rules for enforcing smart-ptr usage?

[David Blaikie]

On Tue, Dec 3, 2013 at 12:19 PM, Fredrik Orderud <forderud at gmail.com> wrote:
> It would be nice with rules for enforcing smart-pointer usage in C++. I
> guess that this can be achieved by disallowing assignment of the
> return-value of "new" to a raw pointer. It would also be possible to
> disallow "delete" altogether, but might be a bit indirect.

With the advent of make_shared and C++14's make_unique you can
potentially disallow 'new' and 'delete' entirely in some codebases
(those not using particularly fancy allocation schemes, etc). Careful
of unique_ptr 'release' of course.

>
> The return-value of "new" should instead be assigned directly to a
> auto_ptr/scoped_ptr/unique_ptr/shared_ptr or other user-defined RAII type.
> Hopefully, a rule wouldn't need to depend on a "whitelist" of pre-approved
> smart-ptr types.
>
> Smart-ptr enforcement is probably not something that everyone would like to
> activate, but it could still be very valuable for avoiding memory & resource
> leaks if it was an optional checker.
>
> Could this be possible to implement?

Unfortunately none of these will be implemented as Clang warnings as
Clang strives to have on-by-default bug-finding warnings only. In
theory things like this should go in a "style plugin" which people
keep talking about, but the Clang plugin support doesn't necessarily
seem up to the task of implementing such a thing in a nice way - but
maybe it's sufficient.

(also, there's the Clang Static Analyzer - but it strives for the same
goal as Clang, low false positive, bug finding warnings - the only
difference being it can expend more resources to find the true
positives while keeping a similar low false positive rate - so it
could find memory leaks when people didn't use unique_ptr, etc, but it
wouldn't aggressively diagnose any raw pointer usage as potentially
leaking)

- David