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

Re: Need help with improving package descriptions for Cppcheck



Reijo Tomperi wrote:
> Thanks to both of you for your previous answers. I tried to combine the  
> best parts from both of the mails and even tried to add some more  
> information about Cppcheck into the description. I'm starting to worry  
> whether it is starting to be too long, or if I'm writing something too  
> biased there.

It is getting a bit long, but I suspect the easiest way of saving
lines is to look for ways of economising on bulletpoints.

> Few notices:
> [...]

Sorry, this part means nothing to me.  I'll stick to combing the
text for English usage problems.  The most obvious is that you've
got too many sentences in a row starting with "Cppcheck..."

> tool for static C/C++ code analysis
>
> Cppcheck is a command-line tool that tries to detect bugs that your  
> C/C++ compiler doesn't see. Cppcheck is versatile, and can check
                              --------
> non-standard code that includes various compiler extensions, inline  
> assembly code, etc. Cppcheck has internal preprocessor which can handle  
                      --------    ^an
> includes, macros and several preprocessor commands. For some checks,
                  ^,
> Cppcheck does quite complex analysis for the variables and it can e.g.  
> track the lifetime of a variable into called function to locate memory  
                                       ^a

I know it's jargon, but tracking a lifetime into a function sounds
very odd - a duration going into a place?  Do people say that?

> leaks and buffer overruns, but it doesn't detect such issues with full  
> accuracy. Cppcheck is configurable, but normal checking requires only a  
            --------
> path to the source file or a folder, so it is easy to take it into use.

Slightly reorganised:

  tool for static C/C++ code analysis
 
  Cppcheck is a command-line tool that tries to detect bugs that your  
  C/C++ compiler doesn't see. It is versatile, and can check non-standard
  code including various compiler extensions, inline assembly code, etc.
  Its internal preprocessor can handle includes, macros, and several
  preprocessor commands. Cppcheck does quite complex analysis for
  variables; for instance it can try to locate memory leaks and buffer
  overruns by tracking variable lifetimes in called functions. While
  Cppcheck is highly configurable, you can start using it just by giving
  it a path to the source code.
  .

> It includes checks for:
> * pointers to out-of-scope auto variables;
> * assignment of auto variables to an effective parameter of a function;
> * out-of-bounds arrays;
> * missing class constructors;
> * variables not initialized by a constructor;
> * use of memset, memcpy, etcetera on a class;
> * non-virtual destructors for base classes;
> * failure of the = operator to return a constant reference to itself;

I thought judging by Jonathan's comments I'd garbled this?  Please
bear in mind that I really don't know what most of these things are!

> * unused private functions;
> * use of deprecated functions (mktemp, gets, scanf);
> * exceptions thrown in destructors;
> * memory leaks in class or function variables;
> * C-style pointer cast in cpp file

(Oh, these are meant to all end in semicolons except the last.)

> * redundant if
> * misuse of the strtol or sprintf functions;
> * unsigned division or division by zero;
> * unused struct members;
> * passing parameters by value;
> * misuse of signed char variables;
> * condition that is always true/false

So would "redundant conditions" cover both this and "redundant if"?

> * unusual pointer arithmetic (such as "abc" + 'd');
> * dereferenced null pointers;
> * incomplete statements;
> * out of bounds errors in STL;

Couldn't bulletpoint number 3 cover this as "out-of-bounds errors in
arrays and STL" (or something)?

> * misuse of iterators when iterating through a container;
> * dereferencing of erased iterators;
> * use of invalidated vector iterators/pointers;
> * functions that are never called.

What's the difference between this and "unused private functions"
above?  Could one or both be merged with "unused struct members"?
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: