1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
[[!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 fuzzying
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]] fuzzying?
|
