SQLITE_MISUSE when a nonsense SQL input is provided, for legacy compatibility.
[forum:/forumpost/4b875d7b2a|Forum post 4b875d7b2a].
FossilOrigin-Name: 1ec2961a0341619ae88832942b52606b3246fc0de07ca6da0300e4bfc656ecf0
[3afaeac56dff58db] (but keep the corresponding test cases) because they
are both made obsolete by the previous fix on this branch.
FossilOrigin-Name: 3120c7c8a3565b8a3ca321129c09db96839c2f9af1777fc7a1668fef81973603
sqlite3ParserAddCleanup().
(dbsqlfuzz b2d11ca70e55ee8bde48ae0b53fa3e9355812f95).
Also add improved testing support by causing sqlite3FaultSim(300) to
simulate an OOM inside of sqlite3ParserAddCleanup() and by adding
improved fault-sim support to the CLI.
FossilOrigin-Name: c6fd70b3c23fa00eaac9286d4a67e5c8ac76f926c11c220250c34032647bedc1
an OOM, since it simulates an OOM. Also fix deferred deletion of Expr objects
from [a53bdd311c4154fd] so that it does not corrupt the AST if an OOM occurs.
FossilOrigin-Name: c623d9a51e0ae6b4a8e1186714d14e7aa3df55246e123323481f07f07749dea5
code, but it is needed to prevent nuisance "stack overflow" reports from
OSSFuzz while it is running the latest ASAN.
FossilOrigin-Name: 70abc144ca90a58ea25dc2d90683545246c084d961215c20ec070b0abe640371
arguments are SQL functions that are able to return subtypes. This closes
a corner-case hole in the patch at [ba789a7804ab96d8].
FossilOrigin-Name: b36d499e4cdb41a5d7e44a1c4347a059d7654f85ade9c5c04d18ac95ddc09fde
marked with SQLITE_RESULT_SUBTYPE, or (2) one of its arguments is a function
that is able to return a subtype. This check-in backs out the code changes
from the previous two on this same branch, but keeps the test cases from
the previous two.
FossilOrigin-Name: f16b200f25a0ec59ad765d254d81c3ffdba21f79e6e82807a7b80d00627952e2
also be marked as SQLITE_RESULT_SUBTYPE, in case one of their arguments has
a subtype.
FossilOrigin-Name: 2f9fba931d9f80b3d5dffb175180098756bccc6a8f665d7aaf8826970ab60d72
from their arguments, and hence need to have the SQLITE_RESULT_SUBTYPE flag
set. This fixes an corner-case for the patch at [ba789a7804ab96d8].
FossilOrigin-Name: cdd1610c44876623e629bb8e5779ea689e6d23c545552b088eca63ad2d1cf8da
[forum:/forumpost/4cf69794d9dfff7c|forum thread 4cf69794d9dfff7c] in two
different ways: (1) Omit the call to PRAGMA integrity_check('X') that was
being done after CREATE TABLE "X" because the result was being ignored and
the integrity_check was not doing anything other than burning CPU cycles.
(2) Do not interpret the argument to PRAGMA integrity_check as a number if it
is in fact a string that looks like a number.
FossilOrigin-Name: 71f08b912251c8a3ac1bd8e344903336648e4187f7493f8c126e60b3b51b9f09
PRAGMA integrity_check as a number. Treat it as a table name that just
happens to look like a number.
FossilOrigin-Name: b04e7a23478f1012e501a810f3e09cca81a66e802f5f72cae80c81120174e2cb
because it is a no-op. Even if the integrity_check failes, the CREATE TABLE
is stull successful. The OP_SqlExec just burns CPU cycles for no reason.
FossilOrigin-Name: 532795acd1c800751737fe70148f9ae691e9cf11b836577f8538421d24cab2fe
The first problem was reported by
[forum:/forumpost/c243b8f856|forum post c243b8f856]. That report prompted
an enhancement to the generate_series() (also included in this merge) which
in turn identified other similar issues.
FossilOrigin-Name: 5f6c079d847e3664ec5acaf1b3e989efe0d548c211ae4a18936162b36df89065
drh