[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: cppcheck, new upstream version 1.31

George Danchev wrote:
On Sunday 12 April 2009 21:45:04 Reijo Tomperi wrote:
Reijo Tomperi wrote:
Dear mentors,


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cppcheck
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget

I checked the latest cppcheck source with the latest binary of cppcheck (as built out of it), and these look like false positives:

[./gui/resultsview.h:66]: (all) Memory leak: ResultsView::mTree [./gui/resultsview.h:72]: (all) Memory leak: ResultsView::mProgress ... [./gui/settingsdialog.h:100]: (all) Memory leak: SettingsDialog::mJobs ...
[./src/tokenize.h:209]: (all) Memory leak: Tokenizer::_tokens

Surely there is something to fix here; either the mysterious memory leaks or their detection ;-)

Thanks, but we know about those already, which is why those checks are behind the --all switch (our dirty and easy escape from false positives).

cppcheck --help

    -a, --all            Make the checking more sensitive. More bugs are
                         detected, but there are also more false positives

But perhaps the error text should be changed to something more revealing. I made a ticket about it:

But these are not regression bugs, they have been there for quite some time.

ps. No upstream changelog yet with this release, sorry. Still trying to
figure out what it should look like (different projects seem to have
different ideas about that) and how to generate it in upstream release.

Maybe you would like to test git2cl [1] a bit.

[1] http://josefsson.org/git2cl/README

Thanks again, but the question is more about whether we should use git logs, or ticket list (of closed tickets), or just the short summary we put in sourceforge news page. Not really sure what people would prefer to see. That probably depends on what they are looking for.

Most common seems to be full list of git logs, similar to what that tool produces. But is that what people really want?

Reply to: