About FlowState in C/C++ DataFlow analysis

[iiins0mn1a]

After reading Java's doc about Flow Label which is pretty much like "FlowState" in C/C++ https://codeql.github.com/docs/codeql-language-guides/using-flow-labels-for-precise-data-flow-analysis/, a C/C++ example in issue #13198 , a python example in discussion #12797 , and some ql-module library source, I think I've got some basic usage of "FlowState". But there are still confusions.

According to my knowledge so far, FlowState attached to source/sink nodes ensure the matching between source node state and sink node state. And this is the impact of using FlowState in the aspect of "result", while I am now interesting about the impact in the aspect of "process".

Like this:

(source1, state1) -> path -> (sink1, state1)
(source2, state1) -> path -> (sink2, state1)
(source3, state2) -> path -> (sink3, state2)

I am curious about the middle of the path.

• 1. I think that FlowState is source/sink nodes dedicated concept, while nodes on-path doesn't have.
• 2. I think (source1, state1) will try to reach the (sink2, state1).
• 3. I think (source1, state1) will not try to reach the (sink3, state2).
• 4. According to question 2/3, state can be used for perfromance optimizing.

[rdmarsh2]

What's actually tracked in the middle of the path is a tuple of the DataFlow::Node, the flow state, and some additional call and field context, and the flow state can be modified partway through the path with an appropriate override of hasAdditionalFlowStep. There's multiple pruning stages that progressively add that information, to avoid tracking too much in the early stages. What will happen is that the path from source1 to sink3 will be eliminated in the stage that adds the flow state into the tuple, but not before that. If you have two sets of sources and sinks that you know shouldn't interact, you're likely to be better off from a performance perspective by writing multiple data flow configurations that won't share their early pruning stages.

[iiins0mn1a]

Thanks for your answer, this is exactly what I want to know, really appreciate!

And about this:

If you have two sets of sources and sinks that you know shouldn't interact, you're likely to be better off from a performance perspective by writing multiple data flow configurations that won't share their early pruning stages.

Actually in my case, I am trying to solve some function pointer problems, which has been discussed in this issule #13198 .
And according to the query provided by @MathiasVP , to whom I am especially grateful, each FunctionAccess as source nodes or each ExprCall as sink nodes have their special signature "Typelist", since in most cases, function pointer's flow should have distinctive characteristic about types of return and arguments.

Then in this situation, I think the FlowState is the only feature I can resort to.

Again, thank you very much, learned a lot!