Documentation Source Text

SQLite has been and continues to be completely free to everyone,
without precondition.

<p>
However, those who wish to participate in the SQLite community,
either by commenting on the public mailing lists or by contributing
patches or suggestions or in any other way,
are expected to conduct themselves in a manner
that honors the overarching spirit of the rule, even if they
disagree with specific details.
Polite and professional discussion is always welcomed, from anyone.

<h1>The Rule</h1>

<ol>

<center>
<table border=1 cellpadding="10" width="80%">
<tr>
<th>Substitution Type<th>Meaning
<tr>
<td>%
<td>Two "%" characters in a row are translated into a single "%" in the output,
    without substituting any values.
<tr>
<td>d, i
<td>The argument is a signed integer which is displayed in decimal.
<tr>
<td>u
<td>The argument is an unsigned integer which is displayed in decimal.
<tr>

<p>Other programming languages sometimes claim to be "as fast as C".
But no other language claims to be faster than C for general-purpose
programming, because none are.

<h2>Compatibility</h2>

<p>Nearly all systems have the ability to call libraries
written in C.  This is not true of other implementation languages.

<p>So, for example, Android applications written in Java are able to
invoke SQLite (through an adaptor).  Maybe it would have been more
convenient for Android if SQLite had been coded in Java as that would
make the interface simpler.  However, on iPhone applications are coded
in Objective-C or Swift, neither of which have the ability to call

objects.  And, to be fair, objects are often a good way to
decompose a problem.  But objects are not the only way, and are
not always the best way to decompose a problem.  Sometimes good old
procedural code is easier to write, easier to maintain and understand,
and faster than object-oriented code.

<li><p>
When SQLite was first being developed, Java was a young and immature
language.  C++ was older, but was undergoing such growing pains that
it was difficult to find any two C++ compilers that worked the same
way.  So C was definitely a better choice back when SQLite was first
being developed.  The situation is less stark now, but there is little
to no benefit in recoding SQLite at this point.
</ol>

<h1>Why Isn't SQLite Coded In A "Safe" Language?</h1>

<p>
There has lately been a lot of interest in "safe" programming languages
like Rust or Go in which it is impossible, or is at least difficult, to make
common programming errors like memory leaks or array overruns.  So the
question often arises as to why SQLite is not coded in a "safe" language.

<ol>
<li><p>
None of the safe programming languages existed for the first 10 years
of SQLite's existance.  SQLite could be recoded in Go or Rust, but doing
so would probably introduce far more bugs than would be fixed, and it
seems also likely to result in slower code.

<li><p>
Safe programming languages solve the easy problems: memory leaks,
use-after-free errors, array overruns, etc.  Safe languages provide
no help beyond ordinary C code in solving the rather more difficult
problem of computing a correct answer to an SQL statement.

<li><p>
Safe languages are often touted for helping to prevent
security vulnerabilities. True enough, but SQLite is
not a particularly security-sensitive library.  If an application is
running untrusted and unverified SQL, then it already has much bigger
security issues (SQL injection) that no "safe" language will fix.
<p>
It is true that applications sometimes import complete binary SQLite
database files from untrusted sources, and such imports could present a
possible attack vector.  However, those code paths in SQLite are
limited and are extremely well tested.  And pre-validation routines 
are available to applications that want to read untrusted databases