ademant
/
gpsd


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159
							<!DOCTYPE HTML>
<html lang="en">
<head lang="en">
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <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">
   <meta name="Revised" content="9 April 2015">
   <meta name="robots" content="index,follow">
   <!-- the following is a verification tag for Google Analytics -->
   <meta name="verify-v1" content="kb4f3qxJPMaOltYTpJHnvbnteza1PHO4EhrRIfcq2gk=">
   <title>GPSd &mdash; 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" height="126"
    width="105"><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>&nbsp;</div>

    <a href='http://www.catb.org/hacker-emblem/'><img
    src='glider.png' alt='hacker emblem' height="55" width="55"></a><br>

    <script src="https://www.openhub.net/p/3944/widgets/project_thin_badge.js"></script>

    <hr>
    <script><!--
    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 src="https://pagead2.googlesyndication.com/pagead/show_ads.js">
    </script>
    <hr>

    <a href="https://validator.w3.org/check/referer"><img
          src="https://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:</p>

<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>Our first Coverity run 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://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>We used to use <a href='http://www.splint.org'>splint</a>, until
we found that we couldn't replicate the results of splint runs
reliably in different Linux distributions. Also, 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. We have retired in favor of more
modern analyzers.</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 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 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"></script>
</div>
</body>
</html>