-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Dataflow: Flow-state changing steps should always be in path explanations #8381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dataflow: Flow-state changing steps should always be in path explanations #8381
Conversation
cf76254
to
cd1f266
Compare
This PR took unbelievably many DCA attempts to run successfully. Here are the final DCA runs:
(They all look fine.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without closely reviewing the code, this sounds like a really good idea 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking a stab at this Mathias. I have an alternative implementation coming up at #8474, which should address my comments.
@@ -1972,6 +1988,13 @@ private module Stage3 { | |||
ap0 instanceof ApNil | |||
) | |||
or | |||
exists(NodeEx mid, FlowState state0, ApNil nil | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change, the code for stages 2-4 are no longer in sync. The local call context checks done by localFlowBigStep
are also omitted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change, the code for stages 2-4 are no longer in sync.
Oops. That's true. I thought I had synced them up, but apparently, I hadn't 🤦.
The local call context checks done by localFlowBigStep are also omitted.
Ah, that's a good point. I guess this is what you fixed with this change in your alternative PR, right?
I must admit I don't fully understand how the dataflow library implements call contexts yet, so I'm not surprised I didn't handle this correctly 😄. Thanks for catching it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's a good point. I guess this is what you fixed with this change in your alternative PR, right?
Yes.
@@ -14,6 +14,8 @@ | |||
| p;InnerHolder;false;getValue;();;Argument[-1];ReturnValue;taint | | |||
| p;InnerHolder;false;setContext;(String);;Argument[0];Argument[-1];taint | | |||
| p;Joiner;false;Joiner;(CharSequence);;Argument[0];Argument[-1];taint | | |||
| p;Joiner;false;Joiner;(CharSequence);;Argument[1];Argument[-1];taint | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can't be right; Argument[1]
does not exist for a constructor with just one argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, yes. Good point. Since you've fixed this in #8474 I won't dive into why that happened (but I'm still kinda curious 🤔).
Thanks a lot for fixing this! In that case, I'll close this PR 👍. |
A taint step that changes the flow-state is almost always going to be interesting for users. So it shouldn't be stepped over by the big step relation.