[pduchi]

I don't have a Trac account, so there is no ticket for this; the details are below. Feel free to create one and I'll add it to the title.

Passing an allocated pointer to a function configured as <use> still gives a --check-library message:

use.cfg:

<memory>
  <alloc>myalloc</alloc>
  <use>set_data</use>
  <dealloc>myfree</dealloc>
</memory>
<function name="myalloc"><noreturn>false</noreturn><arg nr="1"/></function>
<function name="set_data"><noreturn>false</noreturn><arg nr="1"/></function>

use.c:

void f(void)
{
    char *p = myalloc(10);
    set_data(p);
}

$ cppcheck --check-library --library=use.cfg use.c
use.c:5:1: warning: --check-library: Function set_data() should have <use>/<leak-ignore> configuration [checkLibraryUseIgnore]

The cfg reference says <use> exists to silence exactly this message, but CheckLeakAutoVarImpl::configurationInfo() only took <leak-ignore/> into account. It now skips functions that have <use> as well. The leak analysis itself is unchanged.

Test: TestLeakAutoVar::configurationUse; it fails without the change.

[dmcppcheck]

There should probably be a trac ticket for this PR. Please create it, or ask us to create it. Then the PR title should be updated.

[dmcppcheck]

AI review

I found no new problems. With the PR, --check-library stops reporting checkLibraryUseIgnore for functions configured as <use>, both at the end of the scope and on early-return paths. That is what man/reference-cfg-format.md says <use> is for. The leak analysis itself gives the same results as before. The only earlier comment, which asks for a Trac ticket, is still open.

Testing

• I built cppcheck and testrunner in pr/, and cppcheck in base/.
• ./testrunner TestLeakAutoVar TestLeakAutoVarStrcpy TestLeakAutoVarRecursiveCountLimit TestLeakAutoVarWindows TestLeakAutoVarPosix: 161 tests ran, 0 failed. This includes the new configurationUse test.
• Scratch tests. I wrote a custom cfg with <use> entries in a <memory> group (set_data, ns::take) and in a <resource> group (rsetup), then ran cppcheck --check-library --enable=information from PR and base on these cases:
  • Simple case: p is passed to set_data(p). The base reports checkLibraryUseIgnore; the PR does not.
  • Qualified name: passing p to ns::take(p) also gives the message in base and not in the PR.
  • Resource handle: passing an int handle to rsetup(fd) behaves the same way.
  • Early return: with if (set_data(p)) { return; }, base gives two messages (one per path) and the PR gives none.
  • Order of calls: for set_data(p); g(p);, both versions still report g() as needing configuration. For g(p); set_data(p);, neither version reports g(), because the later call already overwrote the possible usage in base.
  • Real leak: set_data(p + 1) gets the same memleak error in both versions.
• Real cfg file: I ran cppcheck with the options from test/cfg/runtests.sh on test/cfg/gtk.c with --library=gtk, which uses many <use> entries. PR and base gave identical output.
• No file in test/cfg or test/cli mentions checkLibraryUseIgnore, so no inline suppression there becomes unmatched.
• I did not run the Python tests in test/cli, because the PR does not touch them.

---

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

[pduchi]

There should probably be a trac ticket for this PR. Please create it, or ask us to create it. Then the PR title should be updated.

Can you create one for me? I send you a private msg ( danielmarjamaki ) in the meantime for getting access to trac with a htpasswd.

[chrchr-github]

I have reservations about <use>. Why do we need that in additon to <leak-ignore/> in a proper <function> configuration?
Also, <use> currently only exists in gtk.cfg.

[dmcppcheck]

Test results for commit 1301cc4 (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8953/
packages: 100
Differing warnings: 0 (+0 -0)
Timing: +0.2% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8953/2026-10-21_19-41-52-1301cc4086f6_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

[pduchi]

I have reservations about <use>. Why do we need that in additon to <leak-ignore/> in a proper <function> configuration? Also, <use> currently only exists in gtk.cfg.

The PR came from the gtk.cfg fix for g_idle_add/g_timeout_add: they take the user data, so their must go. Those functions then have a full configuration without , but --check-library still reports "should have / configuration" for them, which breaks test/cfg. gtk.cfg already uses for this, and the reference (man/reference-cfg-format.md, " and ") says "has no logical purpose ... Use it to silence --check-library information messages", but configurationInfo() never looked at it.

I agree a proper configuration without already says "may take care of the memory". Three ways forward, which do you prefer?

A. Keep this PR as is: configurationInfo() honours , as the reference describes. Small, the leak analysis is unchanged, and no existing expectation changes. But it gives more weight while it only exists in gtk.cfg.
B. configurationInfo() does not report functions that match a library configuration (isNotLibraryFunction()), so is not needed. The only existing expectation that changes is in functionCallCastConfig (#9652). Downside: --check-library no longer flags a configured function whose was forgotten.
C. Drop this PR, and suppress checkLibraryUseIgnore inline in test/cfg/gtk.c for those calls.

[chrchr-github]

I have reservations about <use>. Why do we need that in additon to <leak-ignore/> in a proper <function> configuration? Also, <use> currently only exists in gtk.cfg.

The PR came from the gtk.cfg fix for g_idle_add/g_timeout_add: they take the user data, so their must go. Those functions then have a full configuration without , but --check-library still reports "should have / configuration" for them, which breaks test/cfg. gtk.cfg already uses for this, and the reference (man/reference-cfg-format.md, " and ") says "has no logical purpose ... Use it to silence --check-library information messages", but configurationInfo() never looked at it.

I agree a proper configuration without already says "may take care of the memory". Three ways forward, which do you prefer?

A. Keep this PR as is: configurationInfo() honours , as the reference describes. Small, the leak analysis is unchanged, and no existing expectation changes. But it gives more weight while it only exists in gtk.cfg. B. configurationInfo() does not report functions that match a library configuration (isNotLibraryFunction()), so is not needed. The only existing expectation that changes is in functionCallCastConfig (#9652). Downside: --check-library no longer flags a configured function whose was forgotten. C. Drop this PR, and suppress checkLibraryUseIgnore inline in test/cfg/gtk.c for those calls.

Let me propose
D. Remove <use/> in gtk.cfg and all corresponding code in cppcheck, configure functions with <leak-ignore/> as required. Maybe @danmar can weigh in on this.

[chrchr-github]

Let me propose D. Remove <use/> in gtk.cfg and all corresponding code in cppcheck, configure functions with <leak-ignore/> as required. Maybe @danmar can weigh in on this.

Please disregard, I somehow thought <use/> was synonymous with <leak-ignore/>.

Edit: Although I still fail to see how <use/> is supposed to work even in gtk.cfg.
E.g. there is no memleak warning for

void f() {
    GArray *a = g_array_new(FALSE, FALSE, sizeof(guint));
    g_array_ref(a);
}

g_array_ref() increases the ref count, but does not free its argument.
https://docs.gtk.org/glib/type_func.Array.ref.html