[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

In the topic of *code analysis* or *program analysis* ([[!wikipedia
Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
desc="Wikipedia article"]]).  This topic overlaps with [[performance
analysis|performance]], [[formal_verification]], as well as general
[[debugging]].

[[!toc]]


# Bounty

There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.


# Static

  * [[GCC]]'s warnings.  Yes, really.

  * [Static Source Code Analysis Tools for C](http://spinroot.com/static/)

  * [[!wikipedia List_of_tools_for_static_code_analysis]]

  * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)

    For example, [Debian's hurd_20110319-2
    package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
    (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
    the realloc issues are for real*).

  * Coccinelle

      * <http://lwn.net/Articles/315686/>

      * <http://www.google.com/search?q=coccinelle+analysis>

  * clang

      * <http://www.google.com/search?q=clang+analysis>

  * Linux' sparse

      * <https://sparse.wiki.kernel.org/>

  * <http://klee.llvm.org/>

      * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>

  * [Smatch](http://smatch.sourceforge.net/)

  * [Parfait](http://labs.oracle.com/projects/parfait/)

      * <http://lwn.net/Articles/344003/>

  * [Saturn](http://saturn.stanford.edu/)

  * [Flawfinder](http://www.dwheeler.com/flawfinder/)

  * [sixgill](http://sixgill.org/)

  * [Coverity](http://www.coverity.com/) (nonfree?)


# Dynamic

  * [[community/gsoc/project_ideas/Valgrind]]

  * <http://en.wikipedia.org/wiki/Electric_Fence>

      * <http://sourceforge.net/projects/duma/>

  * <http://wiki.debian.org/Hardening>

  * <https://wiki.ubuntu.com/CompilerFlags>

  * IRC, freenode, #glibc, 2011-09-28

        <vsrinivas> two things you can do -- there is an environment variable
          (DEBUG_MALLOC_ iirc?) that can be set to 2 to make ptmalloc (glibc's
          allocator) more forceful and verbose wrt error checking
        <vsrinivas> another is to grab a copy of Tor's source tree and copy out
          OpenBSD's allocator (its a clearly-identifyable file in the tree);
          LD_PRELOAD it or link it into your app, it is even more aggressive
          about detecting memory misuse.
        <vsrinivas> third, Red hat has a gdb python plugin that can instrument
          glibc's heap structure. its kinda handy, might help?
        <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.

  * Input fuzzing

    Not a new topic; has been used (and a paper published) for early UNIX
    tools, I[[I|tschwinge]]RC.

      * <http://caca.zoy.org/wiki/zzuf>

    What about some [[RPC]] fuzzing?