Skip to content

Conversation

@jbj
Copy link
Contributor

@jbj jbj commented Jan 16, 2019

This is my starting point for resolving https://jira.semmle.com/browse/CPP-318 (see also #597 (comment)). I expect we'll have to iterate for a few rounds to reach a compromise that satisfies all use cases, but I think this is better than the status quo.

In the 3rd commit I've implemented the most extreme of the proposals we've discussed on #597, yet it doesn't affect the test results. That means we need better test cases. Can you come up with a realistic test to show that this change leads to too much data flow?

I hope we agree on the following.

  1. The typical external user of DataFlow should not have to know or worry about Conversions. They will set sources and sinks to unconverted expressions and expect the library to Do What They Mean.
  2. There should be a way for advanced users to specify the precise Conversions for sources and sinks.
  3. We'll need to add further interfaces to let users specify whether to track the pointer or the pointed-to value, but we'll always have a simple predicate like asExpr, which should err on the side of too much data flow.

jbj added 3 commits January 16, 2019 09:47
As we prepare to clarify how conversions are treated, we don't want a
`sink(...)` declaration where it's non-obvious which conversions are
applied to arguments.
With this change, the `IRDataflowTestCommon.qll` and
`DataflowTestCommon.qll` files use the same definitions of sources and
sinks. Since the IR data flow library is meant to be compatible with the
AST data flow library, this is what we ought to be testing.

Two alerts change but not necessarily for the right reasons.
The existing `Node.asExpr` predicate changes semantics so it becomes the
one that most users should use when they don't want to think about
`Conversion`s. A new `Node.asConvertedExpr` predicate is added and has
the same semantics as the old `Node.asExpr` predicate. It's for advanced
users that know about `Conversion`s and want to account for them.
@jbj jbj added the C++ label Jan 16, 2019
@jbj jbj requested a review from dave-bartolomeo January 16, 2019 13:34
@jbj jbj requested a review from a team as a code owner January 16, 2019 13:34
Copy link
Contributor

@dave-bartolomeo dave-bartolomeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think I agree that this is better than the status quo. I'm still uneasy about how this seems to blur the line between a reference and the referred-to object, but I think it's best to have that discussion once we've figured out what the new interface for pointer vs. pointee should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants