port of sqlite3 fuzzer with some updates

testing/libfuzzer/fuzzers/sqlite3_prepare_v2_fuzzer.cc

+// Copyright (c) 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include <stddef.h>
+
+#include "third_party/sqlite/sqlite3.h"
+
+static int Progress(void *not_used_ptr) {
+  return 1;
+}
+
+// Entry point for LibFuzzer.
+extern "C" int LLVMFuzzerTestOneInput(const unsigned char *data, size_t size) {
+  if (size < 2)
+    return 0;
+
+  sqlite3* db;
+  if (SQLITE_OK != sqlite3_open(":memory:", &db))
+    return 0;
+
+  if (data[0] & 1)

[aizatsky, 2015/12/23 21:04:33]

I suggest you add a comment at the top about how you use data.

[inferno, 2015/12/26 22:33:06]

nit: +1 to Mike's comment. I also suggest putting data[0] into a local since it
is used at two places and makes it easier to read.

[mmoroz, 2016/01/15 19:08:16]

Done.

+    sqlite3_progress_handler(db, 10000, &Progress, NULL);
+  else
+    sqlite3_progress_handler(db, 0, NULL, NULL);
+
+  sqlite3_stmt* statement = NULL;
+  int r = sqlite3_prepare_v2(db, (const char*)(data + 1), size - 1,

[inferno, 2015/12/26 22:33:07]

s/r/result

[mmoroz, 2016/01/15 19:08:16]

Done.

+                             &statement, NULL);
+  if (r == SQLITE_OK) {
+    for (int i = 0; i < (data[0] >> 1); i++) {

[inferno, 2015/12/26 22:33:07]

What is reason for >> 1, also use the local defined above ?

[mmoroz, 2016/01/15 19:08:16]

We used least significant bit above for sqlite3_progress_handler selection. Then
we should remove this bit, I think. Otherwise, we always will use loop for odd
number of iterations in cases when progress_handler is used, and always use loop
for even number of iterations in cases without progress_handler.

+      if (sqlite3_step(statement) != SQLITE_ROW)
+        break;
+    }
+
+    sqlite3_finalize(statement);
+  }
+
+  sqlite3_close(db);
+  return 0;
+}