Re: RFS: cppcheck, new upstream version 1.31

[Reijo Tomperi <aggro80@users.sourceforge.net>]

George Danchev wrote:
> On Sunday 12 April 2009 21:45:04 Reijo Tomperi wrote:
> > Reijo Tomperi wrote:
> > > Dear mentors,
>
> Hi,
>
> > 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
> > http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.31-1.dsc
>
> 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

Options:
    -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:
http://apps.sourceforge.net/trac/cppcheck/ticket/251

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?