c - Choosing a static code analysis tool


Translate

I'm working on a project where I'm coding in C in a UNIX environment. I've been using the lint tool to check my source code. Lint has been around a long time (since 1979), can anyone suggest a more recent code analysis tool I could use ? Preferably a tool that is free.


Всички отговори
  • Translate

    Don't overlook the compiler itself.

    Read the compiler's documentation and find all the warnings and errors it can provide, and then enable as many as make sense for you.

    Also make sure to tell your compiler to treat warnings like errors so you're forced to fix them right away. ("-Werror" on gcc)

    Also: "-Wall" on gcc does not enable all warnings, don't be fooled.

    Also also: check out valgrind (free!) - it "automatically detect[s] many memory management and threading bugs, and profile[s] your programs in detail."

    Valgrind isn't a static checker, but it's a great tool! http://valgrind.org


  • Translate

    For C code, you definitely should definitely use Flexelint. I used it for nearly 15 years and swear by it. One of the really great features it has is that warnings can be selectively turned off and on via comments in the code ("/* lint -e123*/"). This turned out to be a powerful documentation tool when you wanted to something out of the ordinary. "I am turning off warning X, therefore, there is some good reason I'm doing X."

    For anybody into interesting C/C++ questions, look at some of their examples on their site and see if you can figure out the bugs without looking at the hints.


  • Translate

    I've heard good things about clang static analyzer, which IIRC uses LLVM as it's backend. If that's implemented on your platform, that might be a good choice.

    From what I understand, it does a bit more than just syntax analysis. "Automatic Bug Finding", for instance.


  • Translate

    We've been using Coverity Prevent to check out C++ source code.

    It's not a free tool (although I believe they offer free scanning for open source projects), but it's one of the best static analysis tools you'll find. I've heard it's even more impressive on C than on C++, but it's helped us avoid quite a number of bugs so far.


  • Translate

    I recently compiled a list of all the static analysis tools I had at my disposal, I am still in the process of evaluating them all. Note, these are mostly security analysis tools.


  • Translate

    You can use cppcheck. It is an easy to use static code analysis tool.
    For example:
    cppcheck --enable=all .
    will check all C/C++ files under the current folder.


  • Translate

    Lint-like tools generally suffer from a "false alarm" problem: they report a lot more issues than really exist. If the proportion of genuinely-useful warnings is too low, the user learns to just ignore the tool. More modern tools expend some effort to focus on the most likely/interesting warnings.


  • Translate

    PC-lint/Flexelint are very powerful and useful static analysis tools, and highly configurable, though sadly not free.

    When first using a tool like this, they can produce huge numbers of warnings, which can make it hard to differentiate between major and minor ones. Therefore, it is best to start using the tool on your code as early in the project as possible, and then to run it on your code as often as possible, so that you can deal with new warnings as they come up.

    With continual use like this, you soon learn how to write your code in a way which confirms to the rules applied by the tool.

    Because of this, I prefer tools like Lint which run relatively quickly, and so encourage continual use, rather than the more cumbersome tools which you may end up using less often, if at all.


  • Translate

    You can try CppDepend, a pretty complete static analyzer available on windows and linux, throught VS Plugin, IDE or command line, and it's free for open source contributors


  • Translate

    You might find the Uno tool useful. It's one of the few free non-toy options. It differs from lint, Flexelint, etc. in focusing on a small number of "semantic" errors (null pointer derefs, out-of-bounds array indices, and use of uninitialized variables). It also allows user-defined checks, like lock-unlock discipline.

    I'm working towards a public release of a successor tool, Orion (CONTENT NOT AVAILABLE ANYMORE)


  • Translate

    There is a "-Weffc++" option for gcc which according to the Mac OS X man page will:

    Warn about violations of the following style guidelines from Scott Meyers' Effective C++ book:

    [snip]

    I know you asked about C, but this is the closest I know of..


  • Translate

    lint is constantly updated... so why would you want a more recent one.

    BTW flexelint is lint


  • Translate

    G'day,

    I totally agree with the suggestions to read and digest what the compiler is telling you after setting -Wall.

    A good static analysis tool for security is FlawFinder written by David Wheeler. It does a good job looking for various security exploits,

    However, it doesn't replace having a knowledgable someone read through your code. As David says on his web page, "A fool with a tool is still a fool!"

    cheers,

    Rob


  • Translate

    I've found that it's generally best to use multiple static analysis tools to find bugs. Every tool is designed differently, and they can find very different things from each other.

    There are some good discussions in some of the talks here. It's from a conference held by the US Department of Homeland Security on static analysis.


  • Translate

    Sparse is a computer software tool, already available on Linux, designed to find possible coding faults in the Linux kernel.

    There are two active projects of Linux Verification Center aimed to improve quality of the loadable kernel modules.

    1. Linux Driver Verification (LDV) - a comprehensive toolset for static source code verification of Linux device drivers.
    2. KEDR Framework - an extensible framework for dynamic analysis and verification of kernel modules.
    3. Another ongoing project is Linux File System Verification that aims to develop a dedicated toolset for verification of Linux file system implementations.