Static analysis of C++ code

META

Activist
SUPREME
MEMBER
Joined
Mar 1, 2026
Messages
118
Reaction score
378
Deposit
0$
For me, the beauty of C++ lies, first and foremost, in the permissiveness and terrifying power of the language. We can work with memory as tightly as in C, while also having abstraction tools like templates and the STL, where you can parameterize anything and everything.
This comes at a price: compiler errors that aren't always clear (try forgetting a semicolon after a class definition), a very long training period for programmers, and, most importantly, some bugs only become apparent during runtime.
We want more useful warnings before our programs run. One way to achieve this is static code analysis. Static means without running the program. I'm interested not only in potential errors, undefined behavior, and memory leaks, but also in things like code unavailability/unusability, and recommendations for making programming style more intuitive.
This article does not discuss software metrics obtained through static analysis. Comments on programming standards (the curly brace should be on a separate line, woohoo!!) are also of no interest.
The evaluation criteria are simple: the number and usefulness of bugs found, ease of use (in particular, the absence of code modification requirements), and free/reasonably priced/good crack.
We'll conduct an initial review and produce a bunch of links:


Found items​


Pedantic gcc keys​


First of all, you should use all available standard tools. gcc provides the following interesting options related to increasing compiler and preprocessor vigilance.
  • -Wall includes all warnings, including compatibility with the new standard, array bounds (in my opinion, it doesn't work, although they say it will work with -O2), volatile/register variables (it will tell you that it doesn't care about your smart words and what //register// and what not, it will decide for itself), sequence points (i++ + ++i)
  • -Wextra - another bunch of warnings like empty bodies in ifs, comparison of signed and unsigned
  • -pedantic — adherence to the ISO C++ standard. For example, prohibiting the long long type.
  • -Weffc++ is a must-have option. It is not enabled with -Wextra or -Wall and includes a check for Scott Meyers' recommendations:
    • Item 11: Define a copy constructor and an assignment operator for classes with dynamically allocated memory.
    • Item 12: Prefer initialization to assignment in constructors.
    • Item 14: Make destructors virtual in base classes.
    • Item 15: Have “operator=” return a reference to *this.
    • Item 23: Don't try to return a reference when you must return an object.
    • Item 6: Distinguish between prefix and postfix forms of increment and decrement operators.
    • Item 7: Never overload "&&", "||", or ",".
  • -Woverloaded-virtual - overloading virtual functions looks bad.
  • -Wctor-dtor-privacy — unused classes with private constructors and destructors
  • -Wnon-virtual-dtor — non-virtual destructor
  • -Wold-style-cast — C-style casting is bad
  • -Werr='warning type' — treat warnings as errors. For tuning samurai, use -Werr without parameters.
  • -Wconversion -Wsign-conversion — a warning about type conversion, which may change the value. Oddly enough, it is not included in -Wall.
  • -Winit-self — int i = i;
  • -Wunreachable-code - code that will never be executed

Of course, I'm not that smart, but I read everything in this man-article about keys related to warnings

Cppcheck​


Perhaps the most reliable program I've found.
The program's official website and its eclipsoid plugin are available. It recognizes quite a lot of errors, including the following:
  • some memory leaks, such as missing delete and delete[], missing delete in destructor
  • going beyond the array boundary
  • exceptions thrown in the destructor
  • null pointer dereference
  • dereference after memory clear
  • virtuality of the base class destructor
  • using the same iterator for different containers
  • various smaller things

It is possible to mark classes as smart pointers (to avoid reporting false memes), GUI on Qt4.

Vera++​


Vera++ , unlike cppcheck, is focused on style checking. It has a continuously updated rule base. By default, the rule base includes a lot of truly idiotic things like "there must be a space before a colon." The only useful feature is disabling the use of using namespace in header files. You can, however, write your own rules in Tcl. :)

RATS​


RATS tells some pretty convincing horror stories about security and buffer overflow attacks. I didn't bother to look closely because I don't know much about secure code.

Checkers for C without pluses​


Surprisingly, pure C programmers seem to care more about static analysis. Here we have a list of questions one and two.

Will they be useful to high-performing developers? If you have classless code and you remember which C++ programs won't compile with a C compiler, then why not?

Splint​


This is the thing for pure C. It assembles practically without effort, but it runs cleanly and searches for a lot of things - see the manual.

Simian​


Simian is a similarity analyzer. It looks for code duplication, that is. Honestly, I haven't thought of any use for it.

CIL​


CIL — C Intermediate Language. Compiles C to simplified C! Simplified C can now be fed to other analyzers, which should theoretically improve their performance.

Incomprehensible, off-topic​


  • Oink . Be careful if you decide to use this. When compiling, I felt like I was building at least a Linux kernel for some exotic architecture. It requires Flex and Bison, which took me a long time to figure out... :) And it also has to fix a ton of compilation errors—it seems the developers not only never run their brainchild, but have never built it. I finally conquered the beast, but the feature list turned out to be anything but impressive. It works with preprocessor files, but produces some kind of nonsense: when I try to sic a simple array bounds error, I get silence. If I feed oink something in C++ with STL, it goes into a tirade that goes on for many, many lines. And this is what I got at the cost of three hours of compiling and editing the source code?
  • Mozilla Dehydra is something based on this very same Oink. I'd be glad if someone could tell me about this checker, because the word Mozilla this time didn't exactly mean "everything is simple and straightforward." I didn't see a list of bugs found, and I didn't feel like compiling it after Oink.
  • There are also compilers that provide more warnings based on static analysis, such as Rose .
  • Rational Purify —the renowned IBM Rational company has its own set of tools for static and dynamic analysis. I'd be happy to hear from anyone about this program; it turns out they only have a Linux trial for the x64 architecture.


Trial/cracked software​


There aren't many of these. There are plenty of analyzers out there that cost a lot of dollars and don't have cracks.
Here's an example of such an analyzer; you can go to their website and request a trial version of Cleanscape . Its capabilities aren't much different from cppcheck.

What else would I like?​


Not all code errors amenable to static analysis were present in existing programs. However, it would be desirable to:
  • Exception specification policy as in Java.
  • using auto_ptr in STL containers, dereferencing auto_ptr after assigning to another auto_ptr.
  • using namespace in h-files
  • overridden delete without new or new without delete
  • call delete[] on non-arrays
  • using a vector with bool values inside
 
Top Bottom