To get a trial key
fill out the form below
Team License (standard version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
An Overview of Static Analyzers for C/C…

An Overview of Static Analyzers for C/C++ Code

May 11 2016

C and C++ programmers tend to make mistakes when writing code.

Many of these mistakes can be found using -Wall, asserts, tests, meticulous code review, IDE warnings, building with different compilers for different operating systems running on different hardware configurations, and the like. But even all these means combined often fail to reveal all the bugs. Static code analysis helps improve the situation a little. In this post, we will take a look at some static analysis tools. [The author of this article is not an employee of our company, and his opinion may be different from ours.]

Cppcheck

Cppcheck is a free open-source (GPLv3) cross-platform static analyzer, which comes as an out-of-the-box solution with many *nix systems. It can also integrate with many IDEs. At the time of writing this article, Cppcheck is a living, evolving project.

Example of use:

cppcheck ./src/

Example of output:

[some.c:57]: (error) Common realloc mistake: 'numarr' nulled
but not freed upon failure

[some.c:154]: (error) Dangerous usage of 'n'
(strncpy doesn't always null-terminate it)

A good thing about Cppcheck is that it is pretty fast. There are no reasons why you shouldn't add it into your continuous integration system so that you could fix each and every warning it generates - even despite that many of these turn out to be false positives.

Official website: http://cppcheck.sourceforge.net/

Clang Static Analyzer

Another free open-source cross-platform static analyzer, which comes as a part of so called "LLVM-stack". Unlike Cppcheck, Clang Static Analyzer is much slower, but it can catch much more critical bugs.

Example of forming an analysis report for PostgreSQL project:

CC=/usr/local/bin/clang38 CFLAGS="-O0 -g" \
  ./configure --enable-cassert --enable-debug
gmake clean
mkdir ../report-201604/
/usr/local/bin/scan-build38 -o ../report-201604/ gmake -j2

Example of forming an analysis report for FreeBSD kernel:

# using custom MAKEOBJDIR allows building the kernel 
# under a non-root account
mkdir /tmp/freebsd-obj
# the build:
COMPILER_TYPE=clang /usr/local/bin/scan-build38 -o ../report-201604/ \
  make buildkernel KERNCONF=GENERIC MAKEOBJDIRPREFIX=/tmp/freebsd-obj

The idea behind it, as you can easily guess, is to clean up the project and then start the build under scan-build.

What you get as the output is a neat HTML report with highly detailed comments, bug filtering by type, and so on. I do recommend that you visit their site for some examples of how it is done.

Since we started talking about it, I can't but mention that the Clang/LLVM infrastructure also provides dynamic analysis tools, known as "sanitizers". There are lots of them; they can catch very tough bugs and run faster than Valgrind (although exclusively on Linux). Unfortunately, discussing sanitizers is beyond the scope of this article, so I recommend that you read about these tools on your own.

Official website: http://clang-analyzer.llvm.org/

PVS-Studio

A proprietary, commercially distributed static analyzer. PVS-Studio runs only on Windows and only with Visual Studio. There is much evidence that a Linux version exists, but you won't find such a version at the official website. As far as I understand, the license price is discussed individually with every customer. A trial version is also available.

I was testing PVS-Studio 6.02 on Windows 7 SP1 running under KVM with Visual Studio 2013 Express Edition. During the PVS-Studio installation, .NET Framework 4.6 was additionally downloaded. This is how the analysis is done: you open a project (I picked PostgreSQL) in Visual Studio, then click on "I'm about to start the build" in PVS-Studio, go to Visual Studio and click on "Build", and when the build is done, you go back to PVS-Studio and click on "Finished" and open the report.

PVS-Studio does know how to catch very tough bugs, which Clang Static Analyzer can't (example). I was also impressed by the interface, which allows you to sort and filter bugs by type, severity, location file, and so on.

On the one hand, it's a pity that your project must be compilable under Windows for you to be able to scan it with PVS-Studio. On the other hand, using CMake with your project to build/test it on various operating systems, including Windows, is a nice idea anyway. So, I guess, the tool being designed for Windows isn't that much of a disadvantage. Besides, here are a few links to some tips from people who managed to run PVS-Studio over projects that don't compile under Windows: one, two, three, four.

Official website: /en/pvs-studio/

Coverity Scan

Coverity is believed to be one of the most sophisticated (and, therefore, expensive) static analyzers. Unfortunately, there is not even a trial version available at the official website. You can try filling out a special form, and in case you work for IBM, you might be lucky enough to hear from them. If you are very eager to get Coverity, you may find some prehistoric versions through unofficial channels. Coverity is available both for Windows and Linux and relies on a similar principle as PVS-Studio. Unlike the latter, though, Coverity will never let you view the report without a key or crack. And to find one or the other, you must try not just very hard, but extremely hard.

Fortunately, Coverity is also available as a SaaS version, which is known as Coverity Scan. Not only is it available to mere mortals, but it is also absolutely free. Coverity Scan is not bound to any particular platform, but you are allowed to use it only on open-source projects.

This is how it works. You register your project through the web interface (or join an already existing project, but this case is not that interesting). For you to be allowed to view the analysis results, your project needs to be approved by an administrator; this procedure takes 1-2 business days.

Analysis reports are formed in the following way. First you build your project locally using special utility Coverity Build Tool, which is similar to scan-build by Clang Static Analyzer and runs on all existing platforms, including various exotic ones such as FreeBSD and even NetBSD.

Coverity Build Tool installation:

tar -xvzf cov-analysis-linux64-7.7.0.4.tar.gz
export PATH=/home/eax/temp/cov-analysis-linux64-7.7.0.4/bin:$PATH

Preparing a test project (I was using the code discussed in the post Going on with Exploration of OpenGL: Simple Text Output (RU):

git clone git@github.com:afiskon/c-opengl-text.git
cd c-opengl-text
git submodule init
git submodule update
mkdir build
cd build
cmake ..

Then we build the project with cov-build:

cov-build --dir cov-int make -j2 demo emdconv

Important! Do not change the name of the cov-int directory.

Pack the cov-int directory into an archive:

tar -cvzf c-opengl-text.tgz cov-int

Then you upload the archive through the Upload form as a Project Build. See instructions at the Coverity Scan site on automating this step using curl. Wait a little, and you can finally view the analysis results. Note that you have to send at least one build for analysis to have it approved by administrators.

Coverity Scan is very good at catching bugs - surely better than Clang Static Analyzer. It produces false positives as well, but there are much fewer of them. The web interface provides a convenient feature, kind of an integrated bug tracker, which allows you to assign different severity levels to bugs, or developers to address them, and so on. It also shows which errors are new and which were already present in the previous builds. Finally, you can mark false positives and hide them.

Note that you don't have to be the owner of a project to get it analyzed by Coverity Scan. For example, I managed to successfully analyze the code of PostgreSQL without joining the already existing project. I suspect that if you really want and try hard enough, you could pass off a bit of not quite open-source code for analysis (for example using Git submodules).

Official website: https://scan.coverity.com/

Conclusion

Here are two more static analyzers, which I didn't elaborate on here:

Each of the analyzers discussed above can catch bugs that none of the others can; so, ideally, you want to use them all at once. In reality, it's hardly possible to maintain this practice all the time for objective reasons; yet giving them at least one run on your project before a release is certainly a good idea. Clang Static Analyzer, however, seems to be the most universal and rather powerful at the same time. If you are looking for one analyzer to use with every project, pick that one. However, I'd still recommend using at least PVS-Studio or Coverity Scan in addition.

What static analyzers have you tried and/or used regularly and what are your impressions of them?

P.S.

This article was written by Russian blogger Aleksandr Alekseev, who kindly permitted us to post it together with the translated version at our site. The original article can be found here: http://eax.me/c-static-analysis/

Popular related articles
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…

Comments (0)

Next comments

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept