Missing ReturnStmt?

Dear All,

I have a very simple clang analyzer checker code snippet like below,

I suspect that this happens because checkers are not run on the Decl
if an error has occurred. In
lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:

void AnalysisConsumer::HandleCode(Decl *D) {

  // Don't run the actions if an error has occurred with parsing the file.
  DiagnosticsEngine &Diags = PP.getDiagnostics();
  if (Diags.hasErrorOccurred() || Diags.hasFatalErrorOccurred())
    return;

Dmitri Gribenko

The analyzer stops analyzing a path when it hits a fail stop bug (because analyzing the rest of the path would be meaningless). In this case, *c = b triggers a warning from the analyzer where ‘c’ is used uninitialized.

Hi Ted,
The dummy example just triggers a warning, I am afraid it shouldn’t stop the analyzer, should it?

Best,
Z

Dear All,

I have a very simple clang analyzer checker code snippet like below,


using namespace clang;
using namespace ento;

namespace {
class myChecker: public Checker< check::PreStmt > {
public:
void checkPreStmt(const Stmt *S, CheckerContext &Ctx) const ;

};
}

void myChecker::checkPreStmt(const Stmt *S, CheckerContext &Ctx) const {
S->dumpAll();
}

This analyzer was then fed with the test code:

int main()
{
int *b;
int *c;
*c=b;
return 0;
}

Why can’t I observe a “ReturnStmt”?
If I change “*c=b” with something other (e.g., b=c), then “ReturnStmt” appears. I just can! 't figure out the reason. Would someone please help me ? Thanks!

What is the command line you use to execute this?

Could it be because ‘*c=b’ causes “Dereference of undefined pointer value” error (in another checker)? Most analyzer errors are defined as sinks - it means that we stop analyzing the path after such error is caught. (This example also produces a compiler warning - you are casting ‘int *’ to ‘int’.)

Anna.

Yes it should. The analysis for Checkers is path-sensitive. Along that path, we hit a bug, flagged by another Checker, that says we should stop analyzing that path. If this kind of path-sensitivity isn’t what you want for your analysis, you should consider writing a different kind of checker that takes an AST and performs its own dataflow analysis that ignores this path-sensitivity.

To Ted,
Yeah, AST is a better choice for me.
To Anna,
I just run “clang -cc1 -analyze -analyzer-checker=experimental.core.myChecker a.c”.

Thank you for your help!
Best,
Zong

All analyzer issues are all printed as warnings. (They are not compilation errors.)

Anna.