[cfe-dev] [Clang Static Analyzer] Lifetime checker
Devin Coughlin via cfe-dev
cfe-dev at lists.llvm.org
Mon Dec 28 12:18:59 PST 2015
> On Dec 21, 2015, at 1:56 AM, Bhargava Shastry via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 1. Why doesn't Clang SA proper not mark `i` as dead on Line 9?
This is something we would definitely like to add support for, especially now that clang is more aggressively exploiting live ranges of local variables in optimizations.
> 2. What is the missing code that can link `i`'s lifetime to validity of `p`?
I haven’t looked into this too deeply, but I think a reasonable approach would be to:
- Add a new kind of LocationContext for the scope of local variables. There is already an (unused!) ScopeContext subclass of LocationContext that seems like it might have been the beginning of work intended for this purpose. You might be able to just use it.
- Change the RegionStore to allow multiple StackLocalsSpaceRegion spaces per frame. I think it might be enough to just change StackLocalsSpaceRegion to take the new local scope context rather than a StackFrameContext.
- Update MemRegionManager::getVarRegion(VarDecl, const LocationContext) to create local variable regions in the correct StackLocalsSpaceRegion for the variable. (There is a FIXME there related to this “FIXME: Once we implement scope handling…”).
- Add a new check::EndLocalScope checker callback (similar to check::EndFunction) to enable checkers to be notified when a local scope is exited.
- Update the CFG and CFGBuilder to keep track of when a local scope begins and ends. (It already does this to be able to to call C++ destructors on locals when they go out of scope, so I don’t think this should be a huge change, but it will need discussion.)
- Update ExprEngine to (a) create a new local scope context when analyzing a scope beginning in the CFG and (b) call the check::EndLocalScope callback when it ends.
- Update the StackAddrEscapeChecker to register for the check::EndLocalScope callback and diagnose when an address of a variable with a no-longer in-scope ScopeContext escapes.
This may seem daunting, but most of these are relatively small changes and we would be happy to provide help and feedback along the way. If you’re up for tackling this, I would suggest taking on the CFG/CFGBuilder changes first because (1) these will have an impact on more than just the analyzer (and so will require a broader discussion) and (2) they can be can be easily tested in isolation.
> I would be happy to contribute patches to catch this simple case.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
More information about the cfe-dev