[cfe-dev] clang-tidy check: Uninitialised primitive members in constructors

Richard legalize at xmission.com
Mon Feb 2 11:25:37 PST 2015


In article <CAAbBDD_qERV4xufHtjBjgQT9m-1AsxretLTS_ABvQGGkeAOX+A at mail.gmail.com>,
    Jonathan Coe <jbcoe at me.com> writes:

> I'm looking to make use of a clang-tidy check that would find (and
> optionally value-initialise) primitive class members (pointers, int,
> doubles etc).
> 
> class C
> {
>   int x_;
> public:
>   C() {} // no x_()
> };
> 
> Is this:
> 
> 1) Already possible? (I can't find it)

I believe so.

> 2) Already work in progress? (I'd like to participate)

I am interested in clang-tidy checkers/fixers that identify the same
issues as cppcheck and this is something that they identify currently.
You can use cppcheck as a reference checking mechanism.

> 3) Possible at all?

Yes.

> 3. Is motivated by my very weak understanding of the matchers, I'm not sure
> if I can match things that are missing if the missing things depend on the
> node I'm looking at. It would be nice to match the compiler generated
> constructor too (and generate one) if that would fail to initialise
> primitives as required.

I would play with clang-query and experiment with the matchers that
you need to identify:

- a class with POD members
- a constructor for a class containing POD members

Maybe you just match all class declarations and all constructors and
you walk through the other information in code in order to identify
"class with POD members".

Your check can maintain state, so you can note that you don't have to
do everything with your matcher.  You can record that you saw a class
with POD members and that a c'tor was declared but not defined so
that when you see the definition after the declaration you know this
is a definition you should drill into more carefully.

Remember that POD members can also be initialized by assignment in the
c'tor, so you'll want to have that to avoid false positives.

Start with the simplest case that you can identify accurately and
correct.  A tool that works correctly for a subset of cases is still
useful.  You can incrementally enhance the check over time to extend
it to more elaborate cases.

Work out of trunk.  A bunch of changes have been made to clang-tidy in
trunk compared to 3.5.

The best thing is probably to post questions to the list as you
encounter them.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>



More information about the cfe-dev mailing list