Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is SQLite Coded In C

sqlite.org

Post reply on HN
Print view View original

151–160 of 411 posts

Re: Why Is SQLite Coded In C

#151

Post by jemmyw »

btilly wrote: post #91
jonahx wrote: post #34

Earlier quoted context omitted.

So is the argument that safe langs produce stuff like: // pseudocode if (i >= array_length) panic("index out of bounds") that are never actually run if the code is correct? But (if I understand correctly) these are checks implicitly added by the compiler. So the objection amounts to questioning the correctness of this auto-generated code, and is predicated upon mistrusting the correctness of the compiler? But presuma…

One of the things that SQLite is explicitly designed to do is have predictable behavior in a lot of conditions that shouldn't happen. One of those predictable behavior is that it does its best to stay up and running, and continuing to do the best it can. Conditions where it should succeed in doing this include OOM, the possibility of corrupted data files, and (if possible) misbehaving CPUs. Automatic array bounds che…

Keeping running if possible doesn't sound like the best strategy for stability. If data was corrupted in memory in a was that would cause a bounds check to fail then carrying on is likely to corrupt more data. Panic, dump a log, let a supervisor program deal with the next step, or a human, but don't keep going potentially persisting corrupted data.

Re: Why Is SQLite Coded In C

#152

Post by afdbcreid »

rednafi wrote: post #60

Also, Rust needs a better stdlib. A crate for every little thing is kinda nuts. One reason I enjoy Go is because of the pragmatic stdlib. On most cases, I can get away without pulling in any 3p deps. Now of course Go doesn’t work where you can’t tolerate GC pauses and need some sort of FFI. But because of the stdlib and faster compilation, Go somehow feels lighter than Rust.

Is Rust's stdlib worse than C's? It's not an argument here.

Re: Why Is SQLite Coded In C

#153

Post by vlovich123 »

btilly wrote: post #91
jonahx wrote: post #34

Earlier quoted context omitted.

So is the argument that safe langs produce stuff like: // pseudocode if (i >= array_length) panic("index out of bounds") that are never actually run if the code is correct? But (if I understand correctly) these are checks implicitly added by the compiler. So the objection amounts to questioning the correctness of this auto-generated code, and is predicated upon mistrusting the correctness of the compiler? But presuma…

One of the things that SQLite is explicitly designed to do is have predictable behavior in a lot of conditions that shouldn't happen. One of those predictable behavior is that it does its best to stay up and running, and continuing to do the best it can. Conditions where it should succeed in doing this include OOM, the possibility of corrupted data files, and (if possible) misbehaving CPUs. Automatic array bounds che…

In rust at least you are free to access an array via .get which returns an option and avoids the “compiler inserted branch” (which isn’t compiler inserted by the way - [] access just implicitly calls unwrap on .get and sometimes the compiler isn’t able to elide).

Also you rarely need to actually access by index - you could just access using functional methods on .iter() which avoids the bounds check problem in the first place.

Re: Why Is SQLite Coded In C

#154

Post by csande17 »

steveklabnik wrote: post #144
csande17 wrote: post #130

Earlier quoted context omitted.

In general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...

What makes you say this is a core part of the marketing strategy? I don’t think Rust’s marketing has ever focused on compiler bugs or their absence.

You are correct that Rust's marketing does not claim that there are no bugs in its compiler. In fact it does the opposite: it suggests that there are no problems with the language, by asserting that any observed issue in the language is actually a bug in the compiler.

Like, in the C world, there's a difference between "the C specification has problems" and "GCC incorrectly implements the C specification". You can make statements about what "the C language" does or doesn't guarantee independently of any specific implementation.

But "the Rust language" is not a specification. It's just a vague ideal of things the Rust team is hoping their compiler will be able to achieve. And so "the Rust language" gets marketed as e.g. having a type system that guarantees memory safety, when in fact no such type system has been designed -- the best we have is a compiler with a bunch of soundness holes. And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug.

This propagates down into things like Rust's claims about backwards compatibility. Rust is only backwards-compatible if your programs are written in the vague-ideal "Rust language". The Rust compiler, the thing that actually exists in the real world, has made a lot of backwards-incompatible changes. But these are by definition just bugfixes, because there is no such thing as a design issue in "the Rust language", and so "the Rust language" can maintain its unbroken record of backwards-compatibility.

Re: Why Is SQLite Coded In C

#155

Post by dathinab »

daxfohl wrote: post #93

It sounds like the core doesn't even allocate, and presumably the extended library allocates in limited places using safe patterns. So there wouldn't be much benefit from Rust anyway, I'd think. Had SQLite ever had a memory leak or use-after-delete bug on a production release? If so, that answers the question. But I've never heard of one. Also, does it use doubly linked lists or graphs at all? Those can, in a way, be…

> Had SQLite ever had a memory leak or use-after-delete bug on a production release?

sure, it's an old library they had pretty much anything (not because they don't know what they are doing but because shit happens)

lets check CVEs of the last few years:

- CVE-2025-29088 type confusion

- CVE-2025-29087 out of bounds write

- CVE-2025-7458 integer overflow, possible in optimized rust but test builds check for it

- CVE-2025-6965 memory corruption, rust might not have helped

- CVE-2025-3277 integer overflow, rust might have helped

- CVE-2024-0232 use after free

- CVE-2023-36191 segmentation violation, unclear if rust would have helped

- CVE-2023-7104 buffer overflow

- CVE-2022-46908 validation logic error

- CVE-2022-35737 array bounds overflow

- CVE-2021-45346 memory leak

...

as you can see the majority of CVEs of sqlite are much less likely in rust (but a rust sqlite impl. likely would use unsafe, so not impossible)

as a side note there being so many CVEs in 2025 seem to be related to better some companies (e.g. Google) having done quite a bit of fuzz testing of SQLite

other takeaways:

- 100% branch coverage is nice, but doesn't guarantee memory soundness in C

- given how deeply people look for CVEs in SQLite the number of CVEs found is not at all as bad as it might look

but also one final question:

SQLite uses some of the best C programmers out there, only they merge anything to the code, it had very limited degree of change compared to a typical company project. And we still have memory vulnerabilities. How is anyone still arguing for C for new projects?

Re: Why Is SQLite Coded In C

#156

Post by hoppp »

jemmyw wrote: post #151
btilly wrote: post #91

Earlier quoted context omitted.

One of the things that SQLite is explicitly designed to do is have predictable behavior in a lot of conditions that shouldn't happen. One of those predictable behavior is that it does its best to stay up and running, and continuing to do the best it can. Conditions where it should succeed in doing this include OOM, the possibility of corrupted data files, and (if possible) misbehaving CPUs. Automatic array bounds che…

Keeping running if possible doesn't sound like the best strategy for stability. If data was corrupted in memory in a was that would cause a bounds check to fail then carrying on is likely to corrupt more data. Panic, dump a log, let a supervisor program deal with the next step, or a human, but don't keep going potentially persisting corrupted data.

It still needs to detect that there is corrupted data, dump the log and the supervisor would not be the best if it was external since in some runtimes it could be missing, they just build it into it and we came full circle.

Re: Why Is SQLite Coded In C

#157

Post by hoppp »

metaltyphoon wrote: post #141
dangus wrote: post #131

Earlier quoted context omitted.

Is SQLite looking for new developers? Will they ever need a large amount of developers like a mega-corp that needs to hire 100 React engineers?

No, but as morbid as this sounds, the three(?) devs one day will pass away so now what?

Then the rights will be sold to a FAANG or an open souce fork like libSQL will live on.

Re: Why Is SQLite Coded In C

#158

Post by hoppp »

steveklabnik wrote: post #27
DarkNova6 wrote: post #19

> 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. Some preconditions that must occur before SQLite is recoded in Rust include: - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. - Rust needs to demonstrate that it can be used to create general-purpos…

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

Rust has dependency hell and supply chain attacks like with npm.

Re: Why Is SQLite Coded In C

#159

Post by hoppp »

aw1621107 wrote: post #145
QuiEgo wrote: post #112

Earlier quoted context omitted.

> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. I’d love to see rust be so stable that MSRV is an anachronism. I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable.

> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?

Fortran, cobol, C or other old languages that stopped changing but are still used.

Re: Why Is SQLite Coded In C

#160

Post by steveklabnik »

hoppp wrote: post #158
steveklabnik wrote: post #27

Earlier quoted context omitted.

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

Rust has dependency hell and supply chain attacks like with npm.

You control the dependencies you put in Cargo.toml.
Post reply on HN