Documentation Source Text

Check-in [d220b2f30c]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Merge changes from the 3.28 branch.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: d220b2f30c431c9a9742881d0410322b6b4faa266af735411baa784ca51c9a9d
User & Date: drh 2019-04-29 16:21:36.705
Context
2019-04-29
18:45
Add documentation for the ".recover" command to the shell tool page. (check-in: 51202caa59 user: dan tags: trunk)
16:21
Merge changes from the 3.28 branch. (check-in: d220b2f30c user: drh tags: trunk)
15:46
Soften the criticism of Go because of their decision to omit assert() from the language. (check-in: 4a40995c05 user: drh tags: branch-3.28)
13:51
Update the file-format document to indicate that de-duplication of index columns in WITHOUT ROWID tables does not occur if the columns have different collating sequences. (check-in: 3047c99f8a user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/assert.in.
︙︙
67
68
69
70
71
72
73



74
75
76
77
78
79
80
81
82

83
84
85
86
87
88
89

An ALWAYS(X) or NEVER(X) macro, or something similar, should be used in 
those cases because ALWAYS(X) or NEVER(X) will be followed by code to
actually deal with the problem when the programmers reasoning
turns out to be wrong.  Since the code that follows ALWAYS(X) or NEVER(X)
is untested, it should be something very simple, like a "return" statement,
that is easily verified by inspection.




<p>The [https://golang.org|Go programming language] omits assert().
The Go developers
[https://golang.org/doc/faq#assertions|recognize this is contentious].
Disallowing assert() is essentially telling developers that they are
not allowed to do run-time verification of invariants.
It is as if the developers of
Go do not want coders to prove the software is correct.
The SQLite developers believe that the lack of assert() disqualifies
Go as a language for serious development work.


<h2>Different Behaviors According To Build Type</h2>

<p>Three separate builds are used to validate the SQLite software.
<ol>
<li> A functionality testing build is used to validate the source code.
<li> A coverage testing build is used to validate the test suite, to confirm








>
>
>
|


<
<
|
<
|
|
>








67
68
69
70
71
72
73
74
75
76
77
78
79


80

81
82
83
84
85
86
87
88
89
90

An ALWAYS(X) or NEVER(X) macro, or something similar, should be used in 
those cases because ALWAYS(X) or NEVER(X) will be followed by code to
actually deal with the problem when the programmers reasoning
turns out to be wrong.  Since the code that follows ALWAYS(X) or NEVER(X)
is untested, it should be something very simple, like a "return" statement,
that is easily verified by inspection.

<p>
Because assert() can be and is commonly misused, some programming language
theorists and designers look with disfavor on the whole idea of assert().
For example, the [https://golang.org|Go programming language] omits assert().
The Go developers
[https://golang.org/doc/faq#assertions|recognize this is contentious].


The SQLite developers agree with those that think the decision to 

omit assert() from Go is a mistake.
It is true that assert() can be misused.  Antibiotics can be misused
too, but that does not mean we should ban all antibiotics.

<h2>Different Behaviors According To Build Type</h2>

<p>Three separate builds are used to validate the SQLite software.
<ol>
<li> A functionality testing build is used to validate the source code.
<li> A coverage testing build is used to validate the test suite, to confirm
︙︙