[cfe-dev] Addressing uninitialized false positives via function/method initialization

[Nathan Herring]

Ran into cases running the clang analyzer against some of my code
where an otherwise uninitialized local is initialized by a function
call or method call, but clang doesn't realize and reports the next
access as uninitialized or garbage. This appears to have at least one
representative bug, 9283.

I'm new to clang, having just gotten an enlistment and source indexing
yesterday, and would like to help work toward contributing a patch to
fix this (and learn the ropes along the way).

I've found the checker involved in CallAndMessageChecker.cpp, but this
appears to be downstream of the problem (not setting the value of the
SVal to something other than uninitialized). I've found
ExprEngine::VisitCall and VisitCXXMemberCallExpr, which is probably
the top of the world where I'd look at function arguments and look for
pointers to non-const Ts and non-const T references and make them
potential binds. Sound good so far? Next -- how do you know whether
the value will be set in the function call? Can we make it more
explicit by annotating the function arguments with something akin to
SAL's __out? Or does this walk down the AST into the call and sees if
the child (or its child, etc., etc.) do the right thing?

I've leafed through some of the Doxygen content for clang and the
InternalsManual page, but haven't seen exactly how this would play
out. Any pointers would be helpful!

Thx in advance,
nh