[cfe-dev] Clang Static Analyzer

Xin Wang via cfe-dev cfe-dev at lists.llvm.org
Mon Jun 19 22:33:59 PDT 2017


Thank you very much!

But I still have a question. I am writing a checker to check if a function
is called during ctor/dtor.

void VirtualCallChecker::checkPreCall(const CallEvent &Call,
                                                        CheckerContext &C)
const {
  const Decl *D = dyn_cast_or_null<Decl>(Call.getDecl());
  if (!D)
    return;
  ProgramStateRef state = C.getState();
  // Enter a constructor, increase the corresponding integer
  if (dyn_cast<CXXConstructorDecl>(D)) {
    unsigned constructorflag = state->get<ConstructorFlag>();
    state = state->set<ConstructorFlag>(++constructorflag);
    C.addTransition(state);
    return;
  }
  if (state->get<ConstructorFlag>() > 0) {
    if (!BT_CT) {
      BT_CT.reset(new BugType(this, "Call to virtual function during
construction",
                  "not pure"));
    }
    ExplodedNode *N = C.generateNonFatalErrorNode();
    auto Reporter = llvm::make_unique<BugReport>(*BT_CT, BT_CT->getName(),
N);
    C.emitReport(std::move(Reporter));
    return;
  }
}

If I use this checker to check the code which use the pointer to construct
the class, it seems that the static analyzer doesn't enter the construction
which is not inline. Is it true that the static analyzer doesn't enter the
exploded graph which is not inline?

Regards,
Xin

2017-06-19 12:00 GMT-07:00 Artem Dergachev <noqnoqneo at gmail.com>:

> It seems that in the first case the analyzer decides to inline the
> constructor - i.e. jump into it and see what exactly is going on inside it,
> and apply these operations within the current analysis. And then it decides
> not to analyze the constructor separately, because it has a better idea
> about this part of the program when it knows what's going on around the
> code.
>
> Normally we don't guarantee that we inline any particular function, just
> try our best. In this case, it might be that the analyzer just wasn't ever
> taught that operator-new calls *that* constructor; instead, he decides to
> behave as if an unknown function is being called.
>
> In fact, you can see and confirm all the details by looking at the
> exploded graphs themselves; they should be quite easy to understand, even
> though they often contain too much information.
>
> On 6/19/17 7:05 PM, Xin Wang via cfe-dev wrote:
>
>> Hello everyone,
>>
>> I have some questions about the exploded graph.
>>
>> /class A {
>> public:
>>   A() {foo();}
>>   void foo();
>> };
>> int main() {
>> /
>> /  A a;
>> /
>> /}
>> /
>> When I use the clang to dump the exploded graph of the code above. There
>> is only one exploded graph.
>>
>> /class A {
>> public:
>>   A() {foo();}
>>   void foo();
>> };
>> int main() {
>>   A *a = new A();
>> /
>> /  delete a;
>> /
>> /}
>>
>> /
>> But when I dump the code above. There is two exploded graph, one for main
>> and another for the construction of the class A.
>>
>> My question is: what is the difference between using the pointer and
>> using the object to initialize a class? Can I use the path-sensitive
>> checker to explore the exploded graph of the construction.
>>
>> Regards,
>> Xin
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170619/f100eb14/attachment.html>


More information about the cfe-dev mailing list