That's why our startup created the sendfile(2) MCP server. Instead of spending $10,000 vibe-coding a codebase that can pass the SQLite test suite, the sendfile(2) MCP supercharges your LLM by streamlining the pipeline between the training set and the output you want.

Just start the MCP server in the SQLite repo. We have clear SOTA on re-creating existing projects starting from their test suite.

This would be relevant if you could find matching code between this and sqlite. But then that would invalidate basically any project as "not flawed" really - given GitHub, there's barely any idea which doesn't have multiple partial implementations already.

Even if was copying sqlite code over, wouldn't the ability to automatically rewrite sqlite in Rust be a valuable asset?

Not really because it's not possible for SQLite written in Rust to pass SQLite's checks. See https://www.sqlite.org/whyc.html

That doesn't seem to support your claim; guessing you mean:

> "2. Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy."

'Safe' languages don't need to do that, if they can verify the array access is always in bounds at compile time then they don't need to emit any code to check it. That aside, it seems like they are saying:

    for (int i=0; i<10; i++) {
        foo(array[i]);
    }

in C might become the equivalent of:

    for (int i=0; i<10; i++) {
        if (i >= array_lower && i < array_higher) {
            foo(array[i]);
        } else {
            ??? // out of bounds, should never happen
        }
    }

in a 'safe' language, and i will always be in inside the array bounds so there is no way to test the 'else' branch?

But that can't be in SQLite's checks as you claim, because the C code does not have a branch there to test?

Either way it seems hard to argue that a bounds test which can never fail makes the code less reliable and less trustworthy than the same code without a bounds test, using the argument that "you can't test the code path where the bounds check which can never fail, fails" - because you can use that same argument "what if the C code for array access which is correct, sometimes doesn't run correctly, you can't test for that"?

Correct, that's what I mean. I trust SQLite's devs to know more about this, so I trust what they wrote. There are parts of Rust code that are basically:

  do_thing().expect(...);

This branch is required by the code, even if it can't be reached, because the type system requires it. It's not possible to test this branch, therefore 100% coverage is impossible in those cases.

That’s not my requirement, that’s SQLite’s requirement. If you want to dispute their claim, I recommend you write to them, however I strongly suspect they know more about this than you do.

I know it's on the sqlite side. I'm familiar with the claim and disagree with it.

You’re arguing in this context:

> wouldn't the ability to automatically rewrite sqlite in Rust be a valuable asset?

If you want to rewrite SQLite, you must accept their position. Otherwise you simply aren’t rewriting SQLite, you’re writing your own database.

Not having bound checks does not make sqlite sqlite. If that was the case, you couldn't compile it with https://clang.llvm.org/docs/BoundsSafety.html turned on and still call it sqlite for example.

The type system does not require that. You can just discard the result:

  let _ = do_thing();

Except that doesn’t work if you need to use the result…