[cfe-dev] Checking if a ParmVarDecl is null in a Checker
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Tue Apr 24 17:07:01 PDT 2018
On 4/24/18 4:54 PM, Timothy J. Wood wrote:
>> On Apr 24, 2018, at 4:44 PM, Artem Dergachev <noqnoqneo at gmail.com
>> <mailto:noqnoqneo at gmail.com>> wrote:
>> Hmm, ok, the problem may also be there:
>>> (void)outError; // Added as a precaution in reference to
>> 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
> 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
The constraint definitely is supposed to remain after the `if`. That's
the whole point of the analyzer. That's essentially the difference
between the exploded graph and your usual CFG.
The constraint itself may disappear when the program no longer
references the constrained symbol, but the two analysis paths are not
merged until they lead to (program state, program point) pairs that are
actually exactly identical in every possible aspect.
> 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.
I still strongly encourage you to have a look at the exploded graph.
It'll immediately explain the whole analysis step-by-step to you and
show you everything that's available on every step and you won't have to
blindly experiment with random callbacks anymore. Please ask if you'll
have problems understanding it.
> Thanks, this gives me a couple paths to try.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev