[chrchr-github]

No description provided.

[chrchr-github]

There already is a test:

cppcheck/test/cfg/std.cpp

Line 5295 in 7b481f4

return m.count(p) > 0;

see https://trac.cppcheck.net/ticket/15194

[dmcppcheck]

AI review

The fix works for the functions it changes. The same constParameterPointer false positive is still there for QMap functions that this PR either touches or sits right next to:

• QMap::value argument 2 (the default value) is unchanged.
• QMap::key argument 2 (the default key) is unchanged.
• QMap::remove is unchanged, and so is QHash::remove.

Code like m.value(k, d), m.key(v, d) or m.remove(k) with int* keys or values still warns. I found no crashes or new false positives. One side effect of indirect="0": passing a dereferenced pointer to these functions, e.g. m.count(*k) with std::map<int,int>, no longer gives constParameterPointer or constVariablePointer. Existing entries that use indirect="0", such as std::vector::push_back, already behave this way.

Testing

• Built cppcheck for pr/ and base/. I did not build testrunner because the PR only changes cfg files and cfg tests.
• test/cfg/qt.cpp and test/cfg/std.cpp pass with the PR cppcheck, using the runtests.sh options (--check-library --check-level=exhaustive --enable=style,information --inconclusive --inline-suppr). There were no unexpected warnings and the exit code was 0.

False positives that remain (scratch/t.cpp):

#include <QMap>
void f_remove(QMap<int*, int*>& m, int* k) { m.remove(k); }
int* f_value2(const QMap<int*, int*>& m, int* k, int* d) { return m.value(k, d); }
int* f_key2(const QMap<int*, int*>& m, int* v, int* d) { return m.key(v, d); }

Command: cppcheck --library=qt -q --enable=style --inconclusive t.cpp

PR output:

4:constParameterPointer:Parameter 'k' can be declared as pointer to const
5:constParameterPointer:Parameter 'd' can be declared as pointer to const
6:constParameterPointer:Parameter 'd' can be declared as pointer to const

QHash::remove(k) gives the same warning: void b(QHash<int*, int*>& m, int* k) { m.remove(k); }.

Side effect (scratch/u.cpp, same command):

int g1(const std::map<int, int>& m, int* k) { return m.count(*k); }
bool g2(const QMap<int, int>& m, int* k) { return m.contains(*k); }
int g3(const std::map<int, int>& m) { int x = 0; int* k = &x; return m.count(*k); }

• base: constParameterPointer for k on lines 3 and 4, and constVariablePointer for k on line 5.
• PR: no warnings.

Existing indirect="0" entries already behave this way: std::vector::push_back(*k) gives no warning in base either.

Other checks: uninitvar for uninitialized keys and values passed to count, value and insert is reported the same in base and PR. The 3-argument insert(pos, k, v) and std::set::count no longer give the false positive.

---

Automated review of bc4ba09 by Claude. The pull request was built and tested locally.

[dmcppcheck]

AI review

QMap::key argument 2 (const Key &defaultKey) still has no indirect="0". Because of that, int* f(const QMap<int*, int*>& m, int* v, int* d) { return m.key(v, d); } still gives constParameterPointer for d.

[dmcppcheck]

AI review

QMap::value argument 2 (const T &defaultValue) still has no indirect="0". Because of that, int* f(const QMap<int*, int*>& m, int* k, int* d) { return m.value(k, d); } still gives constParameterPointer for d. QMap::remove(const Key&) a few lines above was not changed either: void f(QMap<int*, int*>& m, int* k) { m.remove(k); } still warns for k, and QHash::remove does the same.