I wonder why we need so much new code, when there already is a true negative for this:

struct S {
    explicit S(void* p) {
        m = p;
    }
    ~S() {
      free(m);
    }
    void* m = 0;
};

S g(size_t n) {
    return S(malloc(n));
}

void f() {
    S s = g(100);
}

Also see the OP in the forum.

I wonder why we need so much new code, when there already is a true negative for this:

There is a false negative if you remove the call to free. But that's because of this early continue that I don't really understand: https://github.com/cppcheck-opensource/cppcheck/pull/8764/changes#diff-006278020c4bf4fcbe45fbeaeca784b14316e77ceb303853101406d62a7473beR1120.

Also see the OP in the forum.

CheckMemoryLeakInClassImpl only looks for allocations/deallocations in the constructor/destructor, in this case it's allocated outside of the constructor. But yes I should probably reuse some code from that check.

But yes I should probably reuse some code from that check.

Actually I think it's to coupled with the error reporting to be reused in an effective way, so I'll stick with this.