Our team previously used Lint as a static code analyser, but it became too cluttered and had too much noise.
We are using C++03 with frequent use of Boost, and Lint didn't seem to like Boost (I hear this has become better in later versions). I started looking at other static code analysers and came across Cppcheck and tried it out. I'm very impressed at what it warns about (I've seen about a dozen informationals and style problems).
What I'm interested in is: Is there are a list of all Cppcheck messages that Cppcheck issues, similar to how Lint and PVS-Studio both have a list of their messages? The official Cppcheck website lists:
Out of bounds checking
Memory leaks checking
Detect possible null pointer dereferences
Check for uninitialized variables
Check for invalid usage of STL
Checking exception safety
Warn if obsolete or unsafe functions are used
Warn about unused or redundant code
Detect various suspicious code indicating bugs
…
But I'm more interested in something similar to Lint and PVS-Studio, and similar to how the results are displayed in Visual Studio:
ID | Category/Severity | Text
A list of Cppcheck checks is available at the project's wiki, and as stated there, you can also get the list from the command-line by running:
$ cppcheck --doc
or
$ cppcheck --errorlist
The errorlist outputs an XML file with all three things you want. Here's a small example from it:
<error id="unnecessaryForwardDeclaration" severity="style" msg="The variable 'name' forward declaration is unnecessary. Type variable is already declared earlier."/>
<error id="variableHidingEnum" severity="style" msg="variable 'name' hides enumerator with same name"/>
<error id="unnecessaryQualification" severity="style" msg="The extra qualification 'type' is unnecessary and is considered an error by many compilers."/>
To save the output to a file rather than the command window, use:
cppcheck --errorlist > errorlist.xml
Related
I'm cross-compling with mingw and got this error:
undefined reference to `rpl_realloc'
After some searching I found this can be resolved as follows in configure.ac or as environment variables set prior to calling ./mingw64-configure:
ac_cv_func_malloc_0_nonnull=yes
ac_cv_func_realloc_0_nonnull=yes
What defines these macros, and as there any documentation on the subject? I couldn't find any...
What defines these macros, and as there any documentation on the subject?
Autoconf uses the ac_cv_ prefix for its "cache variables", in which it records the results of configuration tests it has performed. In the event that the same check is requested multiple times, these allow it to use the previously-determined result instead of performing the check again.
The general naming convention for these is documented in the Autoconf manual. The particular cache variable names you ask about are documented to cache the results of the Autoconf's AC_FUNC_MALLOC and AC_FUNC_REALLOC macros, respectively. That documentation also speaks to the rpl_realloc name.
It is allowed to use these variables in configure.ac to programmatically determine the results of those checks, but it is a relatively nasty hack to assign values to those variables directly. In this particular case, however, the error suggests that whoever prepared the autotooling for the project you're trying to build did a sloppy job of it. If fudging the cache variables gets you a successful build and a working program then that's a tempting and much easier alternative to actually fixing the project.
I want to create an extension to recognize specific comments in my code. I will use this to signal code smells by using the //# comment prefix. One feature of this extension will be to generate warnings for each comment encountered while compiling the code. Is it possible to do this?
I don't think you can hook into the compiler to generate warning. However, the "Error List" view aggregates errors, warnings and messages from multiple sources. Would it be good enough for you to simply append to that list?
Here's a link I could find on the subject : http://www.mztools.com/articles/2008/MZ2008022.aspx
There is a sample called CodeSweep that detects certain strings in comments (it is written to look for mild swear words) that adds tasks to your Task List. http://code.msdn.microsoft.com/Code-Sweep-3bfb7bb5 Reading this code could help you write your own extension if you can't use it as-is.
You could also use the existing task functionality and add your own keywords (like the out-of-the-box //HACK and //TODO - you could add //SMELL) which is quicker but gives you less control. http://msdn.microsoft.com/en-us/library/zce12xx2(v=VS.100).aspx. This may be all you need.
I have some files that have a particular syntax that is similar to ada (not identical though), however I would like to verify the syntax before going and running them. There isn't a compiler for these files, so I can't check them before using them. I tried to use the following:
gcc -c -gnats <file>
However this says compilation unit expected. I've tried a few variations on this, but to no avail.
I just want to make sure the file is syntactically correct before using it, but I'm not sure how to do it, and I really don't want to write an entire syntax checker just for this.
Is there some way to include an additional unsupported language to gcc without going through a recompile? Also is this simply a file that details to gcc what the syntax constructs are, or what would be entailed? I don't need a full compile, only a syntax check.
Alternately, are there any syntax checkers I can use that I can update an ada syntax check with the small number of changes required for this language?
I've listed Ada as a tag, since the syntax is nearly identical, and finding something that will do ada syntax checking without compiling will be a 90% solution for me.
You could try running the files through gnatchop first. The GCC Ada compiler is rather unique in that it expects filenames to match up with the main unit names inside the file. That may be what your error message is trying to say.
gnatchop will go through any files you give it and write out Ada source files with the appropriate names to make gcc happy (even splitting files into multiple files if needed).
Another option you might be interested in is OpenToken. It is a parser construction toolkit, written in Ada, that allows you to build your own parsers fairly easily. It comes with a syntax recognizer for Ada, so you may just be able to tweak that a bit for your needs.
The project I'm working on recently made a big effort to cleanup the code by turning on all the strictest GCC warnings and iterating until it compiled. Now, for instance, compilation fails if I declare a variable and don't use it.
After my latest development task there I see that there is a header file included somewhere that is now unnecessary. Is there any good way to find other such header files (and in such a way reduce dependencies) other than trying to remove a header file and seeing if anything breaks?
I am using GCC 4.3.2 on Linux.
No, there's no way to get gcc to fail if a header isn't required. Included headers can contain pretty much anything, so it is assumed that whoever included them had good reason to do so. Imagine the following somewhat pathological case:
int some_function(int x) {
#include "function_body.h"
return x;
}
It's certainly not good form, but it would still compile if you removed the include. So, an automatic checker might declare it "unnecessary," even though the behavior is presumably different when the function body is actually there.
Sometimes I need to use a gcc for cross-platform work, and sometimes gcc really amuses me with its warnings. For example:
#pragma once in a main file
This is very informative warning, but I really don't know what a 'main file' IS in terminology of gcc and WHY it must not contain #pragma once :). So, does any documentation exist that covers all gcc warnings and errors (mostly warnings, errors are trivial) with some comments on them?
The objective of '#pragma once' is to prevent a header from being reincluded. If you have it in a source file (usually a '.c' file), you won't be reading that twice (normally - I do know of a source file that reincludes itself [and I don't like it]; it does not use or want #pragma once, though!). So, a 'main file' in this context is one listed on the command line, for instance, rather than a header.
As to the subject matter of the question - the GCC manual does not seem to have a comprehensive list. I don't know whether there actually is one.