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

Re: Need help with improving package descriptions for Cppcheck



Hi,

Reijo Tomperi wrote:

> I'm the maintainer of Cppcheck package and I recently got a bug
> report about the description and as I'm not a technical writer, nor
> am I native English speaker, I'm requestiong help to improve the
> description.

I would normally be hesitant to suggest this, but I suspect it would
be worth revealing more in the description about how cppcheck works
internally.  This is for two reasons:

 - most users of this program would be programmers, so the system
   administrator is likely to understand such commentary;
 - there are many static checkers for C and C++, and the only theme
   I can discern in their differences is what methods they use.

For example, 'sparse' works by giving types to C expressions, and it
is a shame its current package description does not mention that.

I know almost nothing about your package, so what follows is only
meant as an example.

> 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.

I am making up a lot here, so please check my assumptions. ;-)
Maybe cppcheck _does_ track the lifetime of variable.

> You can check non-standard code that includes
> various compiler extensions, inline assembly code, etc. "

Good to know.

> - 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.

> - It can find real bugs from the source code. The kind of bugs that
> can cause e.g. program to crash, misbehave or leak memory.

>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?

It does also seem to do bounds checking, and checking for some
dangerous situations with aliasing, plus some neat checks for
potential optimizations and for likely errors like adding a C string
to a char.

> - 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.

Maybe the point is that cppcheck does not include unreliable warnings
like GCC’s “might be used uninitialized”?

> - There is also a list of checks which can be mentioned by name (see
> the upstream web site for full list), which should perhaps be
> mentioned in the long description. But again I'm not sure how to
> format the list and should all be mentioned or just something?

Hard to say.  If you can find some themes in them, that would be very
useful.  For example:

 Cppcheck performs several types of analysis, including:

  - tracking object lifetimes within a function;
  - bounds checking;
  - checks for object oriented programming best practices in user-
    defined classes (constructors initialize all members, operator=
    returns a const reference, base classes have virtual destructors);
  - detecting uses of confusing language features (such as signed-to-
    unsigned integer promotion and pointer expressions such as "abc" +
    'd');
  - detecting misuse of certain standard library functions.

Hope that helps,
Jonathan


Reply to: