[cfe-dev] Clang Static Analyzer - tracking object value

Jordan Rose jordan_rose at apple.com
Thu May 2 11:44:40 PDT 2013

On Apr 30, 2013, at 5:44 , Gábor Kozár <kozargabor at gmail.com> wrote:

> > ...a lot of C++ objects are value objects, which means they get copied from place to place, and currently it's up to checker writers to determine when that copy happens. Anna actually started sketching out a C++ iterator checker and realized that this problem was nontrivial (though by no means insurmountable).
> I have thought that's what checkBind() is for - but I haven't really looked into what is it that it exactly does. Although I imagine that wrapping an object inside another object would cause complications - because in that case you have to check how the copy ctor behaves in relation to the wrapped object (i.e. is it copied or is a new one created, or is it passed by reference/pointer?), and then track it accordingly. Hmm... yeah, I think can see why this is a non-trivial matter. :) I do find it interesting though - might be something I'll look into during the summer holiday.

checkBind() is a little different from copy-constructing—it's used for low-level "physical" copies while copy-constructing is for "semantic" copies. In C++, every struct copy you do "calls" the copy-constructor for the struct, even if it gets lowered down to a memcpy later anyway. The analyzer similarly will evaluate the copy constructor, allow checkers to do pre- and post-call checks, and then use a low-level bind (if it can) to model the copy. Note that if there's a custom copy constructor, or if any of the members have a custom copy constructor, the low-level bind is no good and the analyzer will have to do a memberwise copy via IPA with the constructor body.

(In light of your other e-mail I should point out that this applies to trunk builds; at 3.2 I believe constructors were still considered opaque, even trivial copy constructors.)

I hope that clears up some of the intent, even if it doesn't directly help you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130502/88a31adb/attachment.html>

More information about the cfe-dev mailing list