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

[Artem Dergachev via cfe-dev]

Yep, indeed, this interface could be improved dramatically with a bit of 
work.

I'm usually getting away pretty well by searching the graph in clever 
manners. If your dot viewer doesn't support text search across the graph 
(most don't), you might want to convert it to .svg (eg. dot -Tsvg 
graph.dot -o graph.svg) and open the svg in a web browser and then use 
the find-on-page feature.


On 4/27/18 3:46 PM, Timothy J. Wood wrote:
>
>> On Apr 24, 2018, at 5:07 PM, Artem Dergachev <noqnoqneo at gmail.com> wrote:
>>
>> 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.
> For extremely simple examples, the exploded graph is sort of tractable, but in large cases it is difficult to figure out what is going on. Maybe I missing something but I’d find it much more useful if I could find a way to:
>
> - Have my custom state (registered with REGISTER_MAP_WITH_PROGRAMSTATE) be logged in the nodes

This can be done by implementing the printState() callback. See 
PthreadLockChecker, MallocChecker, RetainCountChecker, etc. For now not 
many checkers implement it, but i wouldn't mind if all checkers 
implemented it, as long as they don't print anything when they don't 
track anything.

> - Have error nodes marked red

You can use -trim-egraph and you'll only see error nodes and paths 
towards them. Most error nodes would in this case be at the end of the 
trimmed path (though if multiple non-fatal errors are produced on the 
same path, the one in the middle would still not be very apparent).

Also checker error nodes, like all nodes created by the checker, are 
marked with the checker's tag (at the bottom of the rectangle), so you 
can search for the checker name in the graph to find them.

> - Have newly added/updated/removed state called out with some style changes (bold blue for added, bold black for updated, red for removed?)

Yep, that would have been great. I usually get away with searching for 
the specific symbol or region or binding that i'm interested in - it 
immediately highlights where a particular string has disappeared from 
the state.

> - Add log messages of findings in my checker callbacks on the ProgramState or ExplodedNode

I didn't ever try that, but you could probably make nodes with custom 
ProgramPointTag's that contain arbitrary strings.

> These might be a project to tackle on their own, but if there are tips for getting some useful meaning out of the exploded graph, it would be helpful.
>
> Thanks,
>
> -tim
>