C++: Add 'unsafe use of this' query#4644
Conversation
321c3ec to
a330cae
Compare
Co-authored-by: Geoffrey White <40627776+geoffw0@users.noreply.github.com>
…to unsafe-use-of-this-query
b3400c4 to
50ddae4
Compare
50ddae4 to
50e9051
Compare
Co-authored-by: Jonas Jensen <jbj@github.com>
…t-dominance removes some results. Second, that a cast to the pure virtual function's defining class (skipping past a derived class that overrides the function) followed by a call to the function still results in an alert. This is also undefined behavior.
…to unsafe-use-of-this-query
- Remove post-dominance requirement. It was really just hiding good results. - Fix test annotations. Turns out Clang and GCC's 'undefined behavior' warning didn't align with the C++ standard.
|
The code LGTM now! Next steps include qhelp, CPP-Differences and another round of checking the query on lgtm.com. |
I've added qhelp in 020af1c. Here's a fresh LGTM run: https://lgtm.com/query/3939119318730344544/. Removing the post-dominance gave quite a lot of new results that I'm still going through. |
Co-authored-by: hubwriter <hubwriter@github.com>
I've been going through the results on LGTM, and it looks like removing post-dominance didn't introduce new false positives, but just added more flow (since the majority of the sinks didn't happen in a post-dominating position). It looks like it's raising a bunch of alerts on examples that follow this pattern: struct A {
virtual void f() = 0;
};
struct B : public A {
void f() override {}
};
void call_f(A* a) { a->f(); }
struct C : public B {
C() { call_f(this); }
}(which is in the same spirit as the one marked as We can fix this false positive (and all the ones on LGTM) by requiring that there is no override of the pure virtual function being called in any of the base classes of
So I guess it comes down to a choice between
I think I'm leaning toward the last option. I expect more results will pop up as we add more cases of 'must' flow. How does that sound? |
|
I'm on board with the last option too: fewer but better alerts. The two results on LGTM LGTM (argh), and I especially like how clear it is in scummvm on line 51 that they forgot to write |
…sts in any base class. This removes the false positive in the testcase. Based on the results on LGTM we have agreed to set the @precision to very-high.
f2e61ea to
072adaa
Compare
|
|
|
Please merge from |
Done. I've started a fresh CPP-differences with #4696 included: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1562/ |
What a sad CPP-difference 👎 It seems to all be from the new query. I will investigate! Edit: It looks like the new query is causing IR re-evaluation. |
| import cpp | ||
| // We don't actually use the global value numbering library in this query, but without it we end up | ||
| // recomputing the IR. | ||
| private import semmle.code.cpp.valuenumbering.GlobalValueNumbering |
There was a problem hiding this comment.
If this is true shouldn't semmle.code.cpp.valuenumbering.GlobalValueNumbering be imported in semmle.code.cpp.ir.IR, so that all users benefit?
|
648acc3 fixed the IR re-evaluation: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1567/. Performance looks fine now. |


Fixes https://github.com/github/codeql-c-analysis-team/issues/163.
A couple of points are worth making:
thisin C++ constructors (as suggested in the discussion).Since this is 'must' flow, I've designed a tiny ad-hoc 'must' dataflow library in the query. I suspect we could move this ad-hoc library out into a library file and generalize it if it turns out to be useful somewhere else.
For instance, this will not be flagged:
since the call to
finDerived's constructor will callf. However, the query does flag this:since this is undefined behavior (and in practice will crash on the compilers I've tried).
I'm open to discussion on whether or not we want to flag the first example. It should only make the implementation simpler.
We do find some results on LGTM even though we throw away the somewhat benign cases: https://lgtm.com/query/3109442847251804192/.
TODO: