Documentation Source Text

Check-in [538a9a3099]
Login

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

Overview
Comment:Fix a typo in the assert.html document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | branch-3.26
Files: files | file ages | folders
SHA3-256: 538a9a309906a1cddc7d42d619ce6332d465d801c57c71b7fd6fb2123b23330e
User & Date: drh 2018-12-15 11:12:56.520
Context
2018-12-26
12:00
Fix typo on the security.html webpage. (check-in: 2ffc105f81 user: drh tags: branch-3.26)
2018-12-15
11:12
Fix a typo in the assert.html document. (check-in: 538a9a3099 user: drh tags: branch-3.26)
02:51
Fix a typo in the code of ethics. (check-in: 6e0f306cb7 user: drh tags: branch-3.26)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/assert.in.
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
running off the end of the linked list in case there is an error in some
other part of the code that has corrupted the linked list.

<p>
An ALWAYS(X) or NEVER(X) sometimes verifies pre-conditions that are
subject to change if other parts of the code are modified in
subtle ways.  At [https://sqlite.org/src/artifact/18a53540aa3?ln=5512-5516]
we have a case test for two pre-conditions that are true only because
of the limited scope of use of the sqlite3BtreeRowCountEst() function.
Future enhancements to SQLite might use sqlite3BtreeRowCountEst() in
new ways where those preconditions no longer hold, and the NEVER()
macros will quickly alert the developers to that fact when the
situation arises.  But if, for some reason, the pre-conditions are
not satisfied in a release build, the program will still behave sanely
and will not do an undefined memory access.







|







199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
running off the end of the linked list in case there is an error in some
other part of the code that has corrupted the linked list.

<p>
An ALWAYS(X) or NEVER(X) sometimes verifies pre-conditions that are
subject to change if other parts of the code are modified in
subtle ways.  At [https://sqlite.org/src/artifact/18a53540aa3?ln=5512-5516]
we have a test for two pre-conditions that are true only because
of the limited scope of use of the sqlite3BtreeRowCountEst() function.
Future enhancements to SQLite might use sqlite3BtreeRowCountEst() in
new ways where those preconditions no longer hold, and the NEVER()
macros will quickly alert the developers to that fact when the
situation arises.  But if, for some reason, the pre-conditions are
not satisfied in a release build, the program will still behave sanely
and will not do an undefined memory access.