Re: Need help with improving package descriptions for Cppcheck
Jonathan Nieder wrote:
Reijo Tomperi wrote:
The current description is "This program tries to detect bugs that
your C/C++ compiler don't see. The goal is no false positives. Your
compiler can detect many problems that Cppcheck don't try to detect.
Cppcheck is versatile.
Maybe I am too old fashioned, but I would suggest a comparison to
'lint':
Cppcheck is a 'lint'-like tool to analyze C++ code and suggest
potential problems with it. Unlike a compiler, it does not detect
syntax errors; instead, the focus is likely problems that are easy
to detect with some semantic information.
For example, cppcheck does not track the lifetime of variables to
detect all invalid pointers (for that, see valgrind), but it will
warn about functions that return a reference or pointer to an
automatic variable.
It works with C also. So it is important to mention that also as some
skip this tool because the name makes them think it doesn't handle C.
Cppcheck does and does not track the lifetime of a variable. It depends
on the check. For example if you have:
void foo()
{
char *a = malloc(10);
somefunc(a);
}
Cppcheck will go looking for the somefunc() if it finds it, it will
check does it release the memory or not. Only if it is certain that
memory is not released in somefunc() it will print out error about
memory leak. If it doesn't see somefunc(), it will not print out error.
On the other hand, there are a lot of false negatives, because the
lifetime of a variable is not always checked. Cppcheck can detect memory
leaks which valgrind doesn't and valgrind can detect leaks which
Cppcheck doesn't. So not sure if it is worth mentioning about lifetime
at all.
- It also stands out from some of the tools by not requiring valid
syntax and it is possible to check code which uses 3rd party
libraries, non-standard compiler extensions etc.
How does it do this? If this is very robust, that could be very
useful:
It can reliably recover from code it does not understand, which makes
it possible to check code that uses novel language extensions, is
missing headers, or is broken beyond repair.
Obviously we get new bugs every month from code where Cppcheck failed so
not sure how reliable it is. But if there is e.g. function or a macro
which Cppcheck doesn't see, it can still check the file and give errors
it should be able to provide with the information that is given to it.
So missing headers is not a problem for it.
It does this because it doesn't compile the code. It only seeks for
patterns in the code. Like a complex regexp. When it finds something
interesting, e.g. "char a[10];" it will then seek forward for places
where "a" is used to see if there is buffer overrun.
From the checks list, I suspect it enforces an object-oriented style.
Many of the checks seem to overlap with what gcc gives with -Wall
-Wextra -Weffc++; am I understanding correctly?
There is some overlap, but I don't think that there are that many that
overlap? As we understood, the gcc checks are not very good in some
situations. So we tried to write better versions of them. But there
might also be some overlap where we are worse, but this is something we
have tried to avoid.
- It stands out (or at leasts tries to) from other similar tools by
having a low amount of false positives
I don’t get this. For example, memset on a class is perfectly valid
in many situations. Similarly, non-virtual base classes are common
and appropriate in some programming styles.
Cppcheck is not perfect, but we do aim to fix all false positives that
are found. If you think it has a bug, you can create a ticket to
upstream directly and it will be looked into. Usually false positives
are fixed within a month and often within a few days once found:
http://sourceforge.net/projects/cppcheck/
Maybe the point is that cppcheck does not include unreliable warnings
like GCC’s “might be used uninitialized”?
You can enable additional warnings that are similar to your example, but
with default options you should not get anything that is not a bug or at
least dangerous for the future maintainers of the code (e.g. adding
std::string member variable into a class which is memset at some point
will cause problems that a few could expect to happen for doing such
action).
I hope this answers to your questions. I will get back to the
description tomorrow night, as it is now already 1:00 am I need to get
some sleep.
--
Reijo
Reply to: