False negatives: moved standard-library objects are accessed after std::move

CHR — Thu, 30 Jul 2026 12:03:53 -0000

The warnings appear with --inconclusive.

False negatives: moved standard-library objects are accessed after std::move

Rodri — Thu, 30 Jul 2026 11:39:28 -0000

Hi, I found false negatives regarding the rule accessMoved.

Cppcheck misses accesses through member-function calls after moving standard-library objects in the following programs.

Case 1: moved vector queried with `empty()`

#include <iostream>
#include <utility>
#include <vector>

void foo(std::vector<int>);

int main() {
  std::vector<int> v = {1, 2, 3};
  foo(std::move(v));
  if (!v.empty()) {
    std::cout << "Error: Vector not empty";
  }
}

The vector v is moved into foo, then accessed by calling v.empty().

Case 2: moved map queried with `find()`

#include <iostream>
#include <map>
#include <utility>

void foo(std::map<int, int>);

int main() {
  std::map<int, int> m = {{1, 2}};
  foo(std::move(m));
  auto it = m.find(1);
  std::cout << it->second << std::endl;
}

The map m is moved into foo, then accessed by calling m.find(1).

Case 3: moved string queried with `size()`

#include <iostream>
#include <string>
#include <utility>

void foo(std::string);

int main() {
  std::string s = "test";
  foo(std::move(s));
  if (s.size() > 0) {
    std::cout << "Not empty";
  }
}

The string s is moved into foo, then accessed by calling s.size().

Actual result

Cppcheck reports no accessMoved warning for any of the three programs.

Expected result

Cppcheck should report accessMoved for v, m, and s when they are accessed after std::move.

Verification

The issue was reproduced with:

cppcheck --output-format=xmlv2 --enable=all access_moved_vector.cpp
cppcheck --output-format=xmlv2 --enable=all access_moved_map.cpp
cppcheck --output-format=xmlv2 --enable=all access_moved_size.cpp

Version: 2.21.0

False negative: resource leak missed after goto label

Rodri — Thu, 30 Jul 2026 11:36:59 -0000

Hi, I found a false negative regarding the rule resourceLeak.

Cppcheck reports resourceLeak for the original program, but it misses a semantically similar case when the control flow reaches the return statement through a goto label.

Original seed program

#include <stdio.h>

int main()
{
    const FILE *a = fopen("good.c", "r");
    if (!a)
        return 0;

    return 0;
}

Cppcheck reports:

<error id="resourceLeak" severity="error" msg="Resource leak: a" ...>

Reproducing program

#include <stdio.h>

int main() {
  const FILE *a;
  a = fopen("good.c", "r");
  goto check;
check:
  if (!a)
    return 0;
  return 0;
}

In this program, if fopen succeeds, a is returned without being closed by fclose(a), so the file resource is leaked.

Actual result

Cppcheck reports no resourceLeak warning for the reproducing program.

Expected result

Cppcheck should report resourceLeak for a.

Verification

The issue was reproduced with:

cppcheck --output-format=xmlv2 --enable=all resource_leak_goto.cpp

Version: 2.21.0

cppcheck will not recognize a function pointer

CHR — Thu, 30 Jul 2026 10:42:18 -0000

Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14950

cppcheck will not recognize a function pointer

wy163 — Thu, 30 Jul 2026 08:54:28 -0000

Hi,

Below code will be checked as null pointer dereference. But with the function call replaced with a function pointer, no error message will be reported. Seems cppcheck will not recognize a function pointer as a function.

char * func(){return 0;}
int main() {
char * (*f_p)();
f_p = func;
char * p = func();
*p = 'a';
return 0;
}

Nothing reported.

char * func(){return 0;}
int main() {
char * (*f_p)();
f_p = func;
char * p = f_p();
*p = 'a';
return 0;
}

False Positive: Non-Pointer resources deallocated in destructor

Aaron Danen — Wed, 29 Jul 2026 19:22:32 -0000

I made a PR: https://github.com/cppcheck-opensource/cppcheck/pull/8765

Thanks!
Aaron

False Positive: Non-Pointer resources deallocated in destructor

CHR — Wed, 29 Jul 2026 06:46:57 -0000

Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14949
Feel free to open a PR, you seem to have the problem figured out already.

False Positive: Non-Pointer resources deallocated in destructor

Aaron Danen — Tue, 28 Jul 2026 15:38:24 -0000

Hi all

This is my first time posting here so apologies if I mess something up. Also I am very junior (first internship) so I am sorry if I make silly mistakes!

I was using cppcheck on a codebase and found a recurring issue where if memory or a resource is stored in a class/struct, cppcheck will throw a memory leak error even if its deallocated in the objects destructor.

#include <cstdlib>
#include <unistd.h>

class TempFile {
public:
    TempFile(int fd) {
        m_fd = fd;
    }

    ~TempFile() {
      if (m_fd >= 0)
         close(m_fd); 
    }

private:
    int m_fd = -1;
};

TempFile allocateFile(char *name) {
    return TempFile(mkostemp(name, 0));
}

int main() {
    char *ptr = (char *)malloc(10*sizeof(char));
    if (!ptr)
        return 1;

    TempFile f = allocateFile(ptr);
    free(ptr);
    return 0;
}

From my understanding of c++, the destructor of f will be called when main() returns. This would close the file allocated by mkostemp()

Actual result
error: Allocation with mkostemp, TempFile doesn't release it. [leakNoVarFunctionCall]
return TempFile(mkostemp(name, 0));

Expected result
no errors

However, I don't get any issues with a more simple case like this:

#include <cstdlib>

class TempObj {
public:
    TempObj(void *p) {
        ptr = p;
    }

    ~TempObj() {
        if (ptr)
            free(ptr);
    }

private:
    void *ptr = NULL;
};

TempObj allocateMem(int sz) {
    return TempObj(malloc(sz));
}

int main() {
    TempObj t = allocateMem(42);
    return 0;
}

Verification
The issue was produced with:
./cppcheck --library=cfg/gnu.cfg test.cpp
Version: 2.22 dev

path to a solution:
in checkmemoryleak.cpp I found the following:

 void CheckMemoryLeakInClassImpl::check() {
    logChecker("CheckMemoryLeakInClass::check");

    const SymbolDatabase *symbolDatabase = mTokenizer->getSymbolDatabase();
    // only check classes and structures
    for (const Scope * scope : symbolDatabase->classAndStructScopes) {
        for (const Variable &var : scope->varlist) {
              if (!var.isStatic() && (var.isPointer() || var.isPointerArray())) {
                  // allocation but no deallocation of private variables in public function..
                const Token *tok = var.typeStartToken();
                // Either it is of standard type or a non-derived type
                if (tok->isStandardType() || (var.type() && var.type()->derivedFrom.empty())) {
                    if (var.isPrivate())
                        checkPublicFunctions(scope, var.nameToken());
                    variable(scope, var.nameToken());
                }
            }
        }
    }
}

cfg/gnu.cfg defines a resource (the file descriptor) that is allocated by mkostemp() and needs to be "freed" by close(). However, since the var is not a pointer or an array of pointers (its an integer), the if condition

 if (!var.isStatic() && (var.isPointer() || var.isPointerArray()))

blocks the analysis and variable(scope, var.nameToken()) never gets called, so we never inspect the destructor to see if it gets closed.

it seems a similar issue was fixed in
https://github.com/cppcheck-opensource/cppcheck/pull/3832
but I think we need maybe a more general solution, since the library system allows "resources" to be any datatype.

If its helpful I can try to draft a PR but I have never contributed to cppcheck before. I would be happy to review the guidelines and work on it but if you already have something in mind, perhaps its best for you to just fix it.

Thanks for your time,
Aaron

False negative: memleak is missed when main uses a trailing return type

Rodri — Tue, 28 Jul 2026 12:37:42 -0000

Thanks for checking. My report was based on cppcheck 2.21.0. Since HEAD reports the memleak warning correctly, this appears to have already been fixed.

False negative: empty() call suppresses later accessMoved warning for decltype string

CHR — Tue, 28 Jul 2026 06:55:30 -0000

I have filed https://trac.cppcheck.net/ticket/14944 about the inconsistency.

Recent posts to Discussion

False negatives: moved standard-library objects are accessed after std::move

False negatives: moved standard-library objects are accessed after std::move

Case 1: moved vector queried with empty()

Case 2: moved map queried with find()

Case 3: moved string queried with size()

Actual result

Expected result

Verification

False negative: resource leak missed after goto label

Original seed program

Reproducing program

Actual result

Expected result

Verification

cppcheck will not recognize a function pointer

cppcheck will not recognize a function pointer

False Positive: Non-Pointer resources deallocated in destructor

False Positive: Non-Pointer resources deallocated in destructor

False Positive: Non-Pointer resources deallocated in destructor

False negative: memleak is missed when main uses a trailing return type

False negative: empty() call suppresses later accessMoved warning for decltype string

Case 1: moved vector queried with `empty()`

Case 2: moved map queried with `find()`

Case 3: moved string queried with `size()`