-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
C++: Allocate more FunctionInput
and FunctionOutput
s
#14667
C++: Allocate more FunctionInput
and FunctionOutput
s
#14667
Conversation
…utput's for more indirections. Note that we now mark two output nodes coming out of 'getaddrinfo' as a remote flow source (the first indirection and the second indirection). We'll fix that in the next commit.
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.
One small comment.
Regarding the DCA results: are these actually new results, or are they just duplicating existing results?
cpp/ql/lib/semmle/code/cpp/models/interfaces/FunctionInputsAndOutputs.qll
Show resolved
Hide resolved
On Samate this looks like new results 🎉. I'm still checking the other DBs. Edit: The other ones are also new results 🎉. I have yet to find out exactly why we didn't find these results before, but I'm very happy that we now do find them 😂 |
…eref' and accept test changes.
@jketema in 31c2a3b I've reverted the redefinitions of the single-parameter predicates. I've tested that we preserve the test results even if I keep the old definition of of |
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.
Probably want to re-run DCA, other than that LGTM.
Agreed. DCA running now 👍 |
DCA looks fine. The new real-world results are gone, but we still find all the new Samate results. So I'll merge this and we can always investigate why we lost the real-world results again at a later time. |
The modelling language we use for specifying C/C++ models allows us to express stuff like "there's flow from the second indirection of a parameter to the second indirection of the return value" using a model like:
if we add this model to a function
foo
this should ensure that we get flow in an example such as:However, while the modelling interface allowed us to do this, the modelling implementation was hardcoded to only allow
input.isParameterDeref(1)
andoutput.isReturnValueDeref(1)
😱.So this PR bumps those bounds up to
2
. In reality we can probably bump it up arbitrarily large (although we do have to provide some bound to make sure it's all finite), but I didn't want to do that in this PR since I want to get this in quickly to unblock @jketema's work on #14561.Commit-by-commit review recommended.