29 ms·

The SQLite website is a little more positive than that, but as a "quite a bit in the future" option, rather than something that can happen today: > All that sa

The SQLite website is a little more positive than that, but as a "quite a bit in the future" option, rather than something that can happen today: > All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. https://sqlite.org/whyc.html https://sqlite.org/whyc.html

bluGill 6y ago
Good read. It fails by calling C++ a object oriented language, which is false. C++ is a deterministic destruction language. But in the end it doesn't matter, sqlite has been in C long enough that all the hard things C++ gives you for free have been coded manually anyway so there is no real point. For new code C++ might be better, but that is debatable. Just like rust might be better, but that is debatable.
quietbritishjim 6y ago
Thanks for posting that link, it was a very interesting read. I'm a big fan of Rust, but that article really convinced me that C is the best language for SQLite. A couple of highlights IMO: > 2. Safe programming languages solve the easy problems: memory leaks, use-after-free errors, array overruns, etc. Safe languages provide no help beyond ordinary C code in solving the rather more difficult problem of computing a correct answer to an SQL statement. (My commentary) So SQLite development is at such a different level to normal application that the memory safety errors that are a concern for us mortals are the "easy" problems for SQLite developers! > 5. 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. (My commentary) I don't really agree with this one: If a branch cannot possibly be taken then I don't think it counts towards your coverage percentage... just like, if you're careful never to dereference null pointers, you don't include dereferencing null pointers as a missing part of your test coverage. Still, I thought it was very interesting, especially since it's not quite the argument I was expecting (that those checks are wasted CPU time and binary bloat because they're not needed). (Edit: What's more, exactly this situation applies with SQLite's own ALWAYS() and NEVER() macros [1]) [1] https://sqlite.org/assert.html#different_behaviors_according_to_build_type https://sqlite.org/assert.html#different_behaviors_according...
- necovek 6y ago
  Not familiar with the specifics of the SQLite situation, but moving away from 100% means maintaining an exceptions list, introducing complexity and room for error (eg mistakenly adding exceptions when you can't figure out how to reach a branch). If they are at 100% today, it'd be a very convincing argument to keep it that way.
- bluGill 6y ago
  The problem is those branches CAN be taken, otherwise the compiler would optimize them out. So now SQLite needs to figure out how to cause them to be taken to verify that the right thing happens.
rurban 6y ago
The problem is not the implementation language of sqlite, the problem is the author. Hacks upon hacks, and nothing of it in the docs. Instead it represents itself as the most secure of all databases. World class, whilst being worst of its class. Hardening sqlite to get some security back from the insanity internally is a herculean task. I only scratched the surface with mine. Fts accepting custom tokenizers by pointer, dynamically! If someone wants a different tokenizer it needs to compiled in. Simple selects being destructive. https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ https://research.checkpoint.com/2019/select-code_execution-f... No security settings on by default. Dos'able. You can easily overwrite all internal and public tables. A hackers dream. Rust would not help at all, only a proper rewrite.

bluGill 6y ago

Good read. It fails by calling C++ a object oriented language, which is false. C++ is a deterministic destruction language. But in the end it doesn't matter, sqlite has been in C long enough that all the hard things C++ gives you for free have been coded manually anyway so there is no real point. For new code C++ might be better, but that is debatable. Just like rust might be better, but that is debatable.

quietbritishjim 6y ago

Thanks for posting that link, it was a very interesting read. I'm a big fan of Rust, but that article really convinced me that C is the best language for SQLite. A couple of highlights IMO: > 2. Safe programming languages solve the easy problems: memory leaks, use-after-free errors, array overruns, etc. Safe languages provide no help beyond ordinary C code in solving the rather more difficult problem of computing a correct answer to an SQL statement. (My commentary) So SQLite development is at such a different level to normal application that the memory safety errors that are a concern for us mortals are the "easy" problems for SQLite developers! > 5. 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. (My commentary) I don't really agree with this one: If a branch cannot possibly be taken then I don't think it counts towards your coverage percentage... just like, if you're careful never to dereference null pointers, you don't include dereferencing null pointers as a missing part of your test coverage. Still, I thought it was very interesting, especially since it's not quite the argument I was expecting (that those checks are wasted CPU time and binary bloat because they're not needed). (Edit: What's more, exactly this situation applies with SQLite's own ALWAYS() and NEVER() macros [1]) [1] https://sqlite.org/assert.html#different_behaviors_according_to_build_type https://sqlite.org/assert.html#different_behaviors_according...

necovek 6y ago
Not familiar with the specifics of the SQLite situation, but moving away from 100% means maintaining an exceptions list, introducing complexity and room for error (eg mistakenly adding exceptions when you can't figure out how to reach a branch). If they are at 100% today, it'd be a very convincing argument to keep it that way.
bluGill 6y ago
The problem is those branches CAN be taken, otherwise the compiler would optimize them out. So now SQLite needs to figure out how to cause them to be taken to verify that the right thing happens.

rurban 6y ago

The problem is not the implementation language of sqlite, the problem is the author. Hacks upon hacks, and nothing of it in the docs. Instead it represents itself as the most secure of all databases. World class, whilst being worst of its class. Hardening sqlite to get some security back from the insanity internally is a herculean task. I only scratched the surface with mine. Fts accepting custom tokenizers by pointer, dynamically! If someone wants a different tokenizer it needs to compiled in. Simple selects being destructive. https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ https://research.checkpoint.com/2019/select-code_execution-f... No security settings on by default. Dos'able. You can easily overwrite all internal and public tables. A hackers dream. Rust would not help at all, only a proper rewrite.