SQLite

Consider the following test case:

<pre>
CREATE TABLE t0(c0 INT, CHECK(CASE c0 WHEN c0 THEN 0 END));
INSERT INTO t0 VALUES('0'); -- sqlite3.c:86300: sqlite3VdbeExec: Assertion `flags3==pIn3->flags' failed.
</pre>

When compiling with -DSQLITE_DEBUG, the INSERT triggers an assertion error. This bug seems to be a variant of [1b06916e01].

We keep ping-ponging between two bits of code:

  1.  assert( flags3==pIn3->flags );
  2.  testcase( flags3!=pIn3->flags );

The first line says that the conditional is always true.  The second line
says that the conditional is usually true but that we have a test case
for which it is sometimes false.

The test-coverage design rules for SQLite are such that if we do not have
a test case for a conditional, it needs to be inside of an assert() (or
a NEVER() or ALWAYS() depending on circumstances).  On the other hand, if we
believe that a conditional can be either true or false, but no branch operations
depend on that conditional, we need to have a testcase() macro to prove that
we have test cases for both conditions.

When the fuzzer finds new test cases we have to change from (1) to
(2).  Then as we modify the code generator to deal more gracefully with
the strange corner-cases that the fuzzer finds, we have to change from (2)
back to (1).  And back and forth we go.