Documentation Source Text

<hr><i>anonymous claiming to be eas added on 2010-05-07 16:07:41:</i><br>
drh,

The original complaint was definitely correct.  "Insure" means "enter into an insurance contract as the provider".  "Ensure" means "make sure".  Clearly the intent in the doc is the latter.

I was reading through testing.html last night for the umpteenth time and decided it might be helpful to generate a patch for all the typos that leapt out.  That is appended below.

Only the "insure/ensure" thing and other obvious syntactic/spelling/consistency errors are corrected--I've made no attempt at any style prescription.

<verbatim>
--- testing.html    2010-03-31 07:58:55.000000000 -0400
+++ testing.eas.html    2010-05-07 11:01:28.386566309 -0400
@@ -248,7 +248,7 @@
 of SQLite when something goes wrong.  It is (relatively) easy to build
 an SQL database engine that behaves correctly on well-formed inputs
 on a fully functional computer.  It is more difficult to build a system
-that responses sanely to invalid inputs and continues to function following
+that responds sanely to invalid inputs and continues to function following
 system malfunctions.  The anomaly tests are designed to verify the latter
 behavior.</p>

@@ -257,7 +257,7 @@
 <h3>3.1 Out-Of-Memory Testing</h3>

 <p>SQLite, like all SQL database engines, makes extensive use of
-malloc()  (See the separate report on
+malloc(). (See the separate report on
 <a href="malloc.html">dynamic memory allocation in SQLite</a> for
 additional detail.)
 On servers and workstations, malloc() never fails in practice and so correct
@@ -368,7 +368,7 @@
 <h3>3.4 Compound failure tests</h3>

 <p>The test suites for SQLite also explore the result of stacking
-multiple failures.  For example, tests are run to insure correct behavior
+multiple failures.  For example, tests are run to ensure correct behavior
 when an I/O error or OOM fault occurs while trying to recover from a
 prior crash.

@@ -377,7 +377,7 @@
 <h2>4.0 Fuzz Testing</h2>

 <p><a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz testing</a>
-seeks to establish that SQLite response correctly to invalid, out-of-range,
+seeks to establish that SQLite responds correctly to invalid, out-of-range,
 or malformed inputs.</p>

 <h3>4.1 SQL Fuzz</h3>
@@ -434,7 +434,7 @@
 fixed until new test cases have been added to the TCL test suite which
 would exhibit the bug in an unpatched version of SQLite.  Over the years,
 this has resulted in thousands and thousands of new tests being added
-to the TCL test suite.  These regression tests insure that bugs that have
+to the TCL test suite.  These regression tests ensure that bugs that have
 been fixed in the past are not reintroduced into future versions of
 SQLite.</p>

@@ -446,10 +446,10 @@
 are allocated and never freed.  The most troublesome resource leaks
 in many applications are memory leaks - when memory is allocated using
 malloc() but never released using free().  But other kinds of resources
-can also be linked:  file descriptors, threads, mutexes, etc.</p>
+can also be leaked:  file descriptors, threads, mutexes, etc.</p>

 <p>Both the TCL and TH3 test harnesses automatically track system
-resources and report resources leaks on <u>every</u> test run.
+resources and report resource leaks on <u>every</u> test run.
 No special configuration or setup is required.   The test harnesses
 are especially vigilant with regard to memory leaks.  If a change
 causes a memory leak, the test harnesses will recognize this
@@ -482,7 +482,7 @@
 of lines of code are executed at least once by the test suite.</p>

 <p>Branch coverage is more rigorous than statement coverage.  Branch
-coverage measure the number of machine-code branch instructions that
+coverage measures the number of machine-code branch instructions that
 are evaluated at least once on both directions.</p>

 <p>To illustrate the difference between statement coverage and
@@ -575,7 +575,7 @@
 <p>Another macro used in conjunction with test coverage measurement is
 the <tt>testcase()</tt> macro.  The argument is a condition for which
 we want test cases that evaluate to both true and false.
-In non-coverage builds (that is to so, in release builds) the testcase()
+In non-coverage builds (that is to say, in release builds) the testcase()
 macro is a no-op:</p>

 <blockquote><pre>
@@ -585,7 +585,7 @@
 <p>But in a coverage measuring build, the testcase() macro generates code
 that evaluates the conditional expression in its argument.
 Then during analysis, a check
-is made to insure tests exists that evaluate the conditional to both true
+is made to ensure tests exist that evaluate the conditional to both true
 and false.  Testcase() macros are used, for example, to help verify that
 boundary values are tested.  For example:</p>

@@ -612,11 +612,12 @@
 }
 </pre></blockquote>

-<p>For bitmask tests, testcase() macros are used to verify that every
-bit of the bitmask effects the test.  For example, in the following block
+<p>For bitmask tests, <tt>testcase()</tt> macros are used to verify that every
+bit of the bitmask affects the test.  For example, in the following block
 of code, the condition is true if the mask contains either of two bits
-indicating either a MAIN_DB or a TEMP_DB is being opened.  The testcase()
-macros that precede the if statement verify that both cases are tested:</p>
+indicating either a MAIN_DB or a TEMP_DB is being opened.  The 
+<tt>testcase()</tt> macros that precede the <tt>if</tt> statement verify that 
+both cases are tested:</p>

 <blockquote><pre>
 testcase( mask & SQLITE_OPEN_MAIN_DB );
@@ -625,7 +626,7 @@
 </pre></blockquote>

 <p>The SQLite source code contains 558
-uses of the testcase() macro.</p>
+uses of the <tt>testcase()</tt> macro.</p>

 <a name="mcdc"></a>

@@ -710,7 +711,7 @@
 an x86 running a linux binary.  (Ports of valgrind for platforms other
 than linux are in development, but as of this writing, valgrind only
 works reliably on linux, which in the opinion of the SQLite developers
-means that linux should be preferred platform for all software development.)
+means that linux should be the preferred platform for all software development.)
 As valgrind runs a linux binary, it looks for all kinds of interesting
 errors such as array overruns, reading from uninitialized memory,
 stack overflows, memory leaks, and so forth.  Valgrind finds problems
@@ -758,7 +759,7 @@

 <h3>8.5 Journal Tests</h3>

-<p>One of the things that SQLite does to insure that transactions
+<p>One of the things that SQLite does to ensure that transactions
 are atomic across system crashes and power failures is to write
 all changes into the rollback journal file prior to changing the
 database.  The TCL test harness contains an alternative
@@ -805,7 +806,7 @@

 <h2>10.0 Summary</h2>

-<p>SQLite is open source.  This gives many people with the idea that
+<p>SQLite is open source.  This gives many people the idea that
 it is not well tested as commercial software and is perhaps unreliable.
 But that impression is false.
 SQLite has exhibited very high reliability in the field and
</verbatim>