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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Eric S. Raymond">
<meta name="Description" content="gpsd is a utility that can listen to a GPS or AIS receiver and re-publish the positional data in a simpler format.">
<meta name="Keywords" content="GPS, translator, GIS">
<!-- the following is a verification tag for Google Analytics -->
<meta name="verify-v1" content="kb4f3qxJPMaOltYTpJHnvbnteza1PHO4EhrRIfcq2gk=">
<title>GPSd — Put your GPS on the net!</title>
<link rel="stylesheet" href="main.css" type="text/css">
</head>
<body>
<div id="Header">
How We Engineer For High Reliability.
</div>
<div id="Menu">
<img src="gpsd-logo-small.png" alt="Small gpsd Logo"><br>
Home<br>
<div>
<a href="#news">News</a><br>
<a href="#downloads">Downloads</a><br>
<a href="#mailing-lists">Mailing lists</a><br>
<a href="#documentation">Documentation</a><br>
<a href="faq.html">FAQ</a><br>
<a href="xgps-sample.html">Screenshots</a><br>
<a href="#recipes">Recipes</a><br>
<a href="#others">Other GPSDs</a><br>
<a href="hardware.html">Hardware</a><br>
<a href="for-vendors.html">For GPS Vendors</a><br>
<a href="wishlist.html">Wish List</a><br>
<a href="hall-of-shame.html">Hall of Shame</a><br>
<a href="troubleshooting.html">Troubleshooting Guide</a><br>
<a href="hacking.html">Hacker's Guide</a><br>
<a href="references.html">References</a><br>
<a href="protocol-transition.html">Application Compatibility</a>
<a href="history.html">History</a><br>
<a href="future.html">Future</a><br>
</div>
<div> </div>
<a href='http://www.catb.org/hacker-emblem/'><img
src='http://www.catb.org/hacker-emblem/glider.png'
alt='hacker emblem'></a><br>
<script type="text/javascript" src="http://www.ohloh.net/p/3944/widgets/project_thin_badge.js"></script>
<hr>
<script type="text/javascript"><!--
google_ad_client = "pub-1458586455084261";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel = "";
//--></script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
<hr>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401"
alt="Valid HTML 4.01!" height="31" width="88"></a>
</div>
<div id="Content">
<p>GPSD has an exceptionally low defect rate. Our first <a
href='http://coverity.com'>Coverity</a> scan, in March 2007, turned up
only 2 errors in over 22KLOC; our second, in May 2012, turned up just
13 errors in 72KLOC, all on rarely-used code paths. Though the
software is very widely deployed on multiple platforms, we often go
for months between new tracker bugs.</p>
<p>Here's how that's done:</p>
<h2>We have an extensive suite of unit tests and regression tests</h2>
<p>GPSD has around 100 unit tests and regression tests, including sample
device output for almost every sensor type we support. We've put a lot of
effort into making the tests easy and fast to run so they can be run
often. This makes it actively difficult for random code changes to
break our device drivers without somebody noticing.</p>
<p>Which isn't to say those drivers can't be wrong, just that the ways
they can be wrong are constrained to be through either
<ol>
<li> a protocol-spec-level misunderstanding of what the driver is
supposed to be doing, or </li>
<li> an implementation bug somewhere in the program's
state space that is obscure and difficult to reach. </li>
</ol>
</p>
<p>Coverity only
turned up two driver bugs - static buffer overruns in methods for
changing the device's reporting protocol and line speed that escaped
notice because they can't be checked in our test harnesses but only on
a live device.</p>
<p>This is also why Coverity didn't find defects on commonly-used code
paths. If there'd been any, the regression tests probably would have
smashed them out long ago. A great deal of boring, grubby, finicky
work went into getting our test framework in shape, but it has paid
off hugely.</p>
<h2>We use every fault scanner we can lay our hands on.</h2>
<p>We regulary apply Coverity, <a
href='http://www.splint.org'>splint</a>, <a
href='http://sourceforge.net/apps/mediawiki/cppcheck/'>cppcheck</a>,
and <a
href="http://clang-analyzer.llvm.org/scan-build.html">scan-build</a>.
We've as yet been unable to eliminate all scan-build warnings, but we
require the code to audit clean under all the other tools on each
release.</p>
<p>Of these, splint is (a) the oldest, (b) the second most effective
after Coverity at turning up bugs, and (c) far and away the biggest
pain in the ass to use. You have to drop cryptic, cluttery magic
comments all over your source to pass hints to splint and suppress its
extremely voluminous and picky output. The thing is, splint checking
turns up real bugs at a low but consistent rate - one or two each
release cycle.</p>
<p>cppcheck is much newer and much less prone to false
positives. Likewise scan-build. But here's what experience tells us:
each of these three tools finds overlapping but different sets of
bugs. Coverity is, by reputation at least, capable enough that it
might dominate one or more of them - but why take chances? Best to use
all four and constrain the population of undiscovered bugs into as
small a fraction of the state space as we can.</p>
<p>We also use <a href='http://valgrind.org/'>valgrind</a> to check
for memory leaks, though this is not expected to turn up bugs (and
doesn't) due to our no-dynamic-allocation <a href="hacking.html#malloc">house
rule</a>.</p>
<h2>We are methodical and merciless</h2>
<p>Neither magic or genius is required to get defect densities as
low as GPSD's. It's more a matter of sheer bloody-minded persistence -
the willingness to do the up-front work required to apply and
discipline fault scanners, write test harnesses, and automate your
verification process so you can run a truly rigorous validation with
the push of a button.</p>
<p>Many more projects could do this than do. And many more projects
should.</p>
<hr>
<script src="datestamp.js" type='text/javascript'></script>
</div>
</body>
</html>
|
