Documentation Source Text

Building the necessary C programs and transforming and/or creating the
C-language source code for SQLite is a complex process.</p>

<p>To simplify matters, SQLite is also available as a pre-packaged
[amalgamation] source code file: <b>sqlite3.c</b>.  The amalgamation is
a single file of ANSI-C code that implements the entire SQLite library.
The amalgamation is much easier to deal with.  Everything is contained
within a single code files, so it is easy to drop into the source tree
of a larger C or C++ program.  All the code generation and transformation
steps have already been carried out so there are no auxiliary C programs
to configure and compile and no scripts to run.  And, because the entire
library is contained in a single translation unit, compilers are able to
do more advanced optimizations resulting in a 5% to 10% performance 
improvement.  For these reasons, the amalgamation source file 
("<b>sqlite3.c</b>") is recommended for all applications.</p>

Building the necessary C programs and transforming and/or creating the
C-language source code for SQLite is a complex process.</p>

<p>To simplify matters, SQLite is also available as a pre-packaged
[amalgamation] source code file: <b>sqlite3.c</b>.  The amalgamation is
a single file of ANSI-C code that implements the entire SQLite library.
The amalgamation is much easier to deal with.  Everything is contained
within a single code file, so it is easy to drop into the source tree
of a larger C or C++ program.  All the code generation and transformation
steps have already been carried out so there are no auxiliary C programs
to configure and compile and no scripts to run.  And, because the entire
library is contained in a single translation unit, compilers are able to
do more advanced optimizations resulting in a 5% to 10% performance 
improvement.  For these reasons, the amalgamation source file 
("<b>sqlite3.c</b>") is recommended for all applications.</p>

<h4>4.1.1 SQL Fuzz Using The American Fuzzy Lop Fuzzer</h4>

<p>The <a href="http://lcamtuf.coredump.cx/afl/">American Fuzzy Lop</a>
or "AFL" fuzzer is a recent (circa 2014) innovation from Michal Zalewski.
Unlike most other fuzzers that blindly generate random inputs, the AFL
fuzzer instruments the program being tested (by editing the assembly-language
output from the C compiler) and uses that instrumentation to detect when
a mutated input causes the program to do something different - to follow
a new control path or loop a different number of times.  Inputs that provoke
new behavior are retained and further mutated.  In this way, AFL is able
to "discover" new behaviors of the program under test, including behaviors
that were never envisioned by the designers.

<p>AFL has proven remarkably adept at finding arcane bugs in SQLite.
Most of the problems found have been assert() statements where the conditional
could be false under obscure circumstances.  But AFL has also found
a fair number of crash bugs in SQLite, and even a few cases where SQLite 
computed incorrect results.

<p>Because of its past success, AFL became a standard part of the testing
strategy for SQLite beginning with [version 3.8.10].  There is at least one
instance of AFL running against SQLite continuously, 24/7/365, testing new
randomly mutated inputs against SQLite at a rate of a few hundred to a few
thousand per second.  Billions of inputs have been tried, but AFL's 
instrumentation has narrowed that down to less than 20,000 test cases that
cover all distinct behaviors.  These distinct test cases are periodically
captured and added to the [TCL test suite] where they are rerun automatically
during routine testing.

<h3>4.2 Malformed Database Files</h3>

<p>There are numerous test cases that verify that SQLite is able to
deal with malformed database files.
These tests first build a well-formed database file, then add
corruption by changing one or more bytes in the file by some means

<h4>4.1.1 SQL Fuzz Using The American Fuzzy Lop Fuzzer</h4>

<p>The <a href="http://lcamtuf.coredump.cx/afl/">American Fuzzy Lop</a>
or "AFL" fuzzer is a recent (circa 2014) innovation from Michal Zalewski.
Unlike most other fuzzers that blindly generate random inputs, the AFL
fuzzer instruments the program being tested (by editing the assembly-language
output from the C compiler) and uses that instrumentation to detect when
an input causes the program to do something different - to follow
a new control path or loop a different number of times.  Inputs that provoke
new behavior are retained and further mutated.  In this way, AFL is able
to "discover" new behaviors of the program under test, including behaviors
that were never envisioned by the designers.

<p>AFL has proven remarkably adept at finding arcane bugs in SQLite.
Most of the findings have been assert() statements where the conditional
was false under obscure circumstances.  But AFL has also found
a fair number of crash bugs in SQLite, and even a few cases where SQLite 
computed incorrect results.

<p>Because of its past success, AFL became a standard part of the testing
strategy for SQLite beginning with [version 3.8.10].  There is at least one
instance of AFL running against SQLite continuously, 24/7/365, trying new
randomly mutated inputs against SQLite at a rate of a few hundred to a few
thousand per second.  Billions of inputs have been tried, but AFL's 
instrumentation has narrowed them down to less than 20,000 test cases that
cover all distinct behaviors.  Newly discovered test cases are periodically
captured and added to the [TCL test suite].


<h3>4.2 Malformed Database Files</h3>

<p>There are numerous test cases that verify that SQLite is able to
deal with malformed database files.
These tests first build a well-formed database file, then add
corruption by changing one or more bytes in the file by some means