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

[Ted Kremenek]

Hi Nathan,

This may already be fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=128557

What version of the analyzer are you using?

Ted

On Apr 5, 2011, at 6:02 PM, Nathan Herring wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110406/1b206588/attachment.html>