[cfe-dev] Checking if a ParmVarDecl is null in a Checker

[Timothy J. Wood via cfe-dev]

> On Apr 24, 2018, at 4:44 PM, Artem Dergachev <noqnoqneo at gmail.com> wrote:
> 
> Hmm, ok, the problem may also be there:
> 
>> (void)outError; // Added as a precaution in reference to <http://lists.llvm.org/pipermail/cfe-dev/2017-April/053510.html>
> 
> Because in this case you're still doing your check *after* the precaution code which is the last use of the variable.
> 
> You might want to move (or rather duplicate) your check into checkDeadSymbols(). Because once the symbol is dead, there's no way the program would be able to constrain it or initialize the memory it points to. So you can warn immediately when the symbol is dead, based on the information that's already available, assuming that we're still within the function of interest.
> 
> I believe that the check in checkEndFunction is still necessary in case the function of interest is also inlined during analysis, because in this case the symbol may remain alive for a separate reason (still referenced by the caller).
> 
> Note - this is a guess, i didn't actually look at how it works. The easiest way for you to understand that is to dump the "exploded graph" and see everything for yourself, as explained in http://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing <http://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing>


I was guessing that the `outError` would never go out of scope since it is a parameter, but I guess I don’t know for sure that it wouldn’t do so as you suggest. I was starting to guess that the constraint might only be valid inside the two arms of the `if` but that might be misguided. Implementing the `evalAssume` call back, I can that it does mark outError a couple times as well, so that’d be a second option if checkDeadSymbols doesn’t pan out.

Thanks, this gives me a couple paths to try.

-tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180424/5e40b146/attachment.html>