Writing a SQLite clone from scratch in C (2017) • Hacker News Board

Re: Writing a SQLite clone from scratch in C (2017)

#41

Post by saurik » Mon, Jul 05, 2021, 11:24 AM UTC

stux wrote: post #30

saurik wrote: post #11

Earlier quoted context omitted.

> Given the extensive tests written against sqlite, rewriting it from scratch in any language, even a more modern/safer one, would ultimately end up with a buggier program. And yet, people keep finding use-after-free bugs in sqlite3 that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are…

I agree with your general point that "it's very hard to write safe C code", and > people keep finding use-after-free bugs in sqlite3 is true, but > that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are lots more even from just the past year :/ is just incorrect. I'd strongly encourage y…

Well, the first CVE I linked was a bug in the full-text search engine and was confirmed by Apple, so I'm pretty sure I'm correct; but like, even if individual bugs don't manage to affect specific projects, it seems pretty strange to just discount them all out of hand as if they aren't important: even one bug is too many if they are avoidable (and most of these C bugs are).

Re: Writing a SQLite clone from scratch in C (2017)

#42

Post by saurik » Mon, Jul 05, 2021, 11:27 AM UTC

intc wrote: post #27

saurik wrote: post #11

Earlier quoted context omitted.

> Given the extensive tests written against sqlite, rewriting it from scratch in any language, even a more modern/safer one, would ultimately end up with a buggier program. And yet, people keep finding use-after-free bugs in sqlite3 that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are…

I personally don't appreciate the idea of using Rust as an overall "only solution" replacement. Requires LLVM (a huge overkill on a system otherwise based on GCC), no proper support for dynamic linking, own build system, absolutely huge "ecosystem", No standardization (-> no competing implementations), SLOW to compile... Yada-yada. Rust it self also has it's fare share of free after use etc bugs. Please check: https:…

I 100% agree with your complaints about Rust; you might notice that I provided Rust as an example that I dislike, as it is well-known, not as an "only solution". However, I disagree (strongly) with your decision to continued interest in using C: please use almost anything at all other than C (including C++, which isn't perfect but is infinitely better than C++ due to features such as deconstructors).

Re: Writing a SQLite clone from scratch in C (2017)

#43

Post by saurik » Mon, Jul 05, 2021, 11:29 AM UTC

kahlonel wrote: post #29

saurik wrote: post #11

Earlier quoted context omitted.

> Given the extensive tests written against sqlite, rewriting it from scratch in any language, even a more modern/safer one, would ultimately end up with a buggier program. And yet, people keep finding use-after-free bugs in sqlite3 that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are…

> The underlying thing to appreciate here is that the goal is to make these kinds of mistakes not only much harder but impossible Hate to break it to you, but it is not "impossible" to have CVEs in Rust [1]. 1. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

Of course, but I would argue those aren't the same "kind of mistake".

Re: Writing a SQLite clone from scratch in C (2017)

#44

Post by varajelle » Mon, Jul 05, 2021, 12:14 PM UTC

jcelerier wrote: post #36

varajelle wrote: post #34

Earlier quoted context omitted.

Don't write faillible constructor. Instead, you can write a static method that returns a std::optional, for example.

That does not work for data members, unless you are willing to have the entirety of your software wrapped and unwrapped in optionals up to main, which looks pretty much like what people had in the 70s and thought : "okay, maybe there is a language feature we could have to abstract that repetitive mess"

Just have the non-throwing private constructor take the data member by rvalue reference and move them in place. This works in practice for so many projects that do C++ without exceptions.

Re: Writing a SQLite clone from scratch in C (2017)

#45

Post by jcelerier » Mon, Jul 05, 2021, 1:54 PM UTC

varajelle wrote: post #44

jcelerier wrote: post #36

Earlier quoted context omitted.

That does not work for data members, unless you are willing to have the entirety of your software wrapped and unwrapped in optionals up to main, which looks pretty much like what people had in the 70s and thought : "okay, maybe there is a language feature we could have to abstract that repetitive mess"

Just have the non-throwing private constructor take the data member by rvalue reference and move them in place. This works in practice for so many projects that do C++ without exceptions.

But then you loose so many features of C++. Can't have aggregates anymore since everything needs private constructors -> more code -> more bugs.

Each possible contructor now needs a matching static method.

Can't put things in standard containers unless you rewrite all copy / move contructors (and you didn't forget to mark your move constructor noexcept, did you ?).

What happens when you have classes with more than 3 members ? Constructors with 12 arguments ? That's unambiguously terrible, and does not even save you from exceptions coming from C++ itself.

If 79% of surveyed C++ projects can use exceptions (https://www.jetbrains.com/lp/devecosystem-2020/cpp/), likely so can you.

Re: Writing a SQLite clone from scratch in C (2017)

#46

Post by dleslie » Mon, Jul 05, 2021, 2:35 PM UTC

_d7dt wrote: post #18

dleslie wrote: post #14

Earlier quoted context omitted.

It pains me that Rust targets LLVM, and doesn't use C as an intermediary language. I would _love_ to use Rust on embedded and older hardware on which LLVM simply isn't available.

I'm not sure what value you're suggesting rustc would be able to bring there. If you want that in LLVM you can try your luck with the "resurrected" C backend: https://github.com/JuliaComputingOSS/llvm-cbe I don't understand why I see so many requests for LLVM-based languages to change around their backend or IR, that seems to be a huge amount of work for comparatively little benefit. The correct thing to do there is…

I don't want to "try my luck", I want to build software.

GCC, and various proprietary vendor compilers, are often the only C compilers available on some hardware; and llvm doesn't have a mature, stable and supported backend for them, either.

Re: Writing a SQLite clone from scratch in C (2017)

#47

Post by hitekker » Mon, Jul 05, 2021, 3:24 PM UTC

stux wrote: post #30

saurik wrote: post #11

Earlier quoted context omitted.

> Given the extensive tests written against sqlite, rewriting it from scratch in any language, even a more modern/safer one, would ultimately end up with a buggier program. And yet, people keep finding use-after-free bugs in sqlite3 that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are…

I agree with your general point that "it's very hard to write safe C code", and > people keep finding use-after-free bugs in sqlite3 is true, but > that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are lots more even from just the past year :/ is just incorrect. I'd strongly encourage y…

In addition, I recommend others read https://news.ycombinator.com/item?id=27736216. It’s a thoughtful discussion that dispels the unintentional FUD of this thread.

Before today, I didn’t know that CVEs aren’t vetted and can be easily spammed for self-gain[1]. I should be more skeptical the next time I see scores of links to CVEs with 0 comments and bare-bones descriptions.

[1] https://news.ycombinator.com/item?id=25612429