virtual method calls in ctor/dtor

Hi all,

before I implement it by myself I'd rather ask. Maybe there is already a solution or it is not as simple as I thought.
The question is, whether or not it is possible to implement a warning about direct or indirect calls to virtual methods within ctors or dtors.
My approach would be to generate the cfg of the examined ctor/dtor and then traverse the execution paths and see if there is such a call. The interesting/difficult thing could be to keep track of the "this" pointer, since calls by other objects should not lead to such a warning.

What do you think?

Best Olaf

If you're thinking of doing this as a Clang warning just a few thoughts

* it won't be interprocedural - that's just not practical at
compile-time. So you won't catch the indirect calls (dtor calls free
function foo, passing 'this, foo then calls virtual function on the
passed in pointer)
* you probably don't want/need the CFG - that's for path sensitive
analysis. In this case I don't think there's anything path-sensitive
you need to worry about, so you can probably just do this warning on
the fly - you see a call, you check whether we're currently parsing
the body of a dtor, then you check if it's a member call to the same
object (again, probably best to just catch simple cases like
"this->x()" or "x()" and not worry about "foo *f = this; ... f->x()")
* Getting such a warning into Clang has a somewhat high bar. We avoid
having warnings in Clang that have a high false positive (where "false
positive" is any case where the warning fires and the users code
doesn't have a bug, generally speaking) rate and I'm not sure if this
warning would meet that bar without some heuristics/improvements - but
I haven't given it much consideration just yet, perhaps you have ideas
there.

For the record, there's an alpha static analyzer checker for this: alpha.cplusplus.VirtualCall. I'm not quite sure what state it's in; it's been a long time since anyone's worked on it. It's purely doing a syntactic check, though; if you want the check to be interprocedural, it should be converted to path-sensitive.

In either the warning or static analyzer case, I would suggest allowing the warning to be silenced if the user explicitly writes a non-virtual call, e.g. ThisClass::doSomething().

Jordan