Documentation Source Text

      puts "$srcfile: bad requirement: [string range $nx 0 40]..."
      set x $nx
      continue
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &amp; &} $req]
    set req [string trim $req]
    set reqno R-[md5-10x8 $req]
    db eval {SELECT srcfile AS s2, reqtext as r2
             FROM requirement WHERE reqno=$reqno} {
      puts "$srcfile: duplicate [string range $reqno 0 12] in $s2: \[$r2\]"
    }
    db eval {
................................................................................
    } else {
      regexp {^([^<]|<.+?>)*?\.} $nx req
      regsub {^([^<]|<.+?>)*?\.} $nx {} nx
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &amp; &} $req]
    set req [string trim $req]
    set rno R-[md5-10x8 $req]
    set shortrno [string range $rno 0 12]
    append out "<a name=\"$rno\"></a><font color=\"blue\"><b>\n"
    set link "<a href=\"$matrixpath#$rno\" style=\"color: #0000ff\">"
    append out "$link$shortrno</a>:\[</b></font>"
    if {$proof($rno)>=2} {

      puts "$srcfile: bad requirement: [string range $nx 0 40]..."
      set x $nx
      continue
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &#91; [ &#93; ] &amp; &} $req]
    set req [string trim $req]
    set reqno R-[md5-10x8 $req]
    db eval {SELECT srcfile AS s2, reqtext as r2
             FROM requirement WHERE reqno=$reqno} {
      puts "$srcfile: duplicate [string range $reqno 0 12] in $s2: \[$r2\]"
    }
    db eval {
................................................................................
    } else {
      regexp {^([^<]|<.+?>)*?\.} $nx req
      regsub {^([^<]|<.+?>)*?\.} $nx {} nx
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &#91; [ &#93; ] &amp; &} $req]
    set req [string trim $req]
    set rno R-[md5-10x8 $req]
    set shortrno [string range $rno 0 12]
    append out "<a name=\"$rno\"></a><font color=\"blue\"><b>\n"
    set link "<a href=\"$matrixpath#$rno\" style=\"color: #0000ff\">"
    append out "$link$shortrno</a>:\[</b></font>"
    if {$proof($rno)>=2} {

Most developers should be able to completely ignore this document
and simply build SQLite from
<a href="amalgamation.html">the amalgamation</a> without any
special knowledge and without taking any special actions.</i></blockquote>

<p>However, highly tuned and specialized
applications may want or need to replace some of
SQLite's built-in system interface with alternative implementations
more suitable for the needs of the application.  SQLite is designed
to be easily reconfigured at compile-time to meet the specific
needs of individual projects.  Among the compile-time configuration
options for SQLite are these:</p>

<ul>
<li><p> Replace the built-in mutex subsystem with an alternative
................................................................................
There is also on-going work with experimental memory allocators that
satisfy all memory requests from a single fixed memory buffer handed
to SQLite at application start.  Additional information on these
experimental memory allocators will be provided in a future revision
of this document.</p>

<p>SQLite supports the ability of an application to specify an alternative



memory allocator at run-time using the [sqlite3_config()] interface.
For example:</p>

<blockquote><pre>
sqlite3_config(SQLITE_CONFIG_MALLOC, dlmalloc, dlfree, dlrealloc, dlmalloc_usable_size);
</pre></blockquote>

<p>The [SQLITE_CONFIG_MALLOC] setting to [sqlite3_config()] passes four
function pointers into SQLite.  The first three functions work exactly
like malloc(), free(), and realloc(), respectively, from the standard
C library.  The fourth function pointer must be for a routine that
returns the size of a memory allocation given a pointer to that allocation.
In the default memory allocator implementation for SQLite, these fourth
"memsize" function is implemented by prepending an 8-byte size integer
to the beginning of every allocation.  The memsize function is not a
standard part of must memory alloction libraries and so must be implemented
in this way.  However, Doug Lea's dlmalloc implementation, as shown in the
example above, does provide an implementation of memsize which, if used,
reduces the size overhead and execution time of every memory allocation
and deallocation.</p>

<p><i>TBD: Talk about alternative zero-malloc implementations and how to
select them at compile-time.</i></p>

<p><i>TBD: Talk about how to disable any built-in memory allocator so that
an application is required to register the memory allocator at
startup.</i></p>

<h2>4.0 Adding New Virtual File Systems</h2>

<p>Since [version 3.5.0], SQLite has supported an interface called the
[sqlite3_vfs | virtual file system] or "VFS".
This object is somewhat misnamed since it
is really an interface to whole underlying operating system, not
just the filesystem.</p>

<p> One of the interesting features
of the VFS interface is that SQLite can support multiple VFSes at the
same time.  Each [database connection] has to choose a single VFS for its
use when the connection is first opened using [sqlite3_open_v2()].
But if a process contains multiple [database connections] each can choose

Most developers should be able to completely ignore this document
and simply build SQLite from
<a href="amalgamation.html">the amalgamation</a> without any
special knowledge and without taking any special actions.</i></blockquote>

<p>However, highly tuned and specialized
applications may want or need to replace some of
SQLite's built-in system interfaces with alternative implementations
more suitable for the needs of the application.  SQLite is designed
to be easily reconfigured at compile-time to meet the specific
needs of individual projects.  Among the compile-time configuration
options for SQLite are these:</p>

<ul>
<li><p> Replace the built-in mutex subsystem with an alternative
................................................................................
There is also on-going work with experimental memory allocators that
satisfy all memory requests from a single fixed memory buffer handed
to SQLite at application start.  Additional information on these
experimental memory allocators will be provided in a future revision
of this document.</p>

<p>SQLite supports the ability of an application to specify an alternative
memory allocator at run-time by filling in an instance of the
[sqlite3_mem_methods] object with pointers to the routines of the
alternative implementation then registering the new alternative
implementation using the [sqlite3_config()] interface.
For example:</p>

<blockquote><pre>
sqlite3_config(SQLITE_CONFIG_MALLOC, &my_malloc_implementation);
</pre></blockquote>

<p>SQLite makes a copy of the content of the [sqlite3_mem_methods] object
so the object can be modified after the [sqlite3_config()] call returns.</p>



















<h2>4.0 Adding New Virtual File Systems</h2>

<p>Since [version 3.5.0], SQLite has supported an interface called the
[sqlite3_vfs | virtual file system] or "VFS".
This object is somewhat misnamed since it
is really an interface to the whole underlying operating system, not
just the filesystem.</p>

<p> One of the interesting features
of the VFS interface is that SQLite can support multiple VFSes at the
same time.  Each [database connection] has to choose a single VFS for its
use when the connection is first opened using [sqlite3_open_v2()].
But if a process contains multiple [database connections] each can choose