1 files changed, 98 insertions, 0 deletions
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
new file mode 100644
index 00000000..7495221b
--- /dev/null
+++ b/open_issues/code_analysis.mdwn
@@ -0,0 +1,98 @@
+[[!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.