In my opinion, you don't get to ask "why is X done by Y" before you've done X yourself by something not Y and not Y by proxy either.
Why Is SQLite Coded In C
271–280 of 411 posts
Re: Why Is SQLite Coded In C
#272“None of the safe programming languages existed for the first 10 years of SQLite's existence. SQLite could be recoded in Go or Rust, but doing so would probably introduce far more bugs than would be fixed, and it may also result in slower code.” Modern languages might do more than C to prevent programmers from writing buggy code, but if you already have bug-free code due to massive time, attention, and testing, and t…
The author cleverly leaves out all the safer alternatives that have existed outside UNIX, and what was happening with computers outside Bell Labs during the 1970's. Not only was Apple was able to launch the Mac Classic with zero lines of C code, their Pascal dialect lives on in Delphi and Free Pascal. As one example.
Isn’t Pascal just as problematic as C in this respect? And the original Mac was mostly (all?) assembly, not Pascal. They couldn’t have used a higher level language anyway. The system was just too small for that. SQLite wouldn’t fit on it.
Re: Why Is SQLite Coded In C
#273Earlier quoted context omitted.
Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.
This is a bit of a misunderstanding. Safe code is just code that cannot have Undefined Behavior. C and C++ have the concept of "soundness" just like Rust, just no way to statically guard against it.
Modern compilers like clang and GCC both have static analysis for some of this. Check out the undefined behavior sanitizer.
Re: Why Is SQLite Coded In C
#274Earlier quoted context omitted.
It's the sort of argument that I wouldn't accept from most people and most projects, but from Dr Hipp isn't most people and Sqlite isn't most projects.
It's a bad argument. Certainly don't get me wrong, SQLite is one of the best and most thoroughly tested libraries out there. But this was an argument to have 4 arguments. That's because 2 of the arguments break down as "Those languages didn't exist when we first wrote SQLite and we aren't going to rewrite the whole library just because a new language came around." Any language, including C, will emit or not emit inst…
Autovectorization / unrolling can maybe still be handed with a couple of additional tests.
The main problem I see with doing branch coverage on compiled machine code is inlining: instead of two tests for one branch, you now need two tests for each function that a copy of the branch was inlined into.
Re: Why Is SQLite Coded In C
#275Earlier quoted context omitted.
It's not like that, the compiler explicitly doesn't do compile-time checks here and offloads those to the runtime. Rust does not stop you from writing code that accesses out of bounds, at all. It just makes sure that there's an if that checks.
Ok, but you can still test all the branches in your source code and have 100% coverage. Those additional `if` branches are added by the compiler. You are responsible for testing the code you write, not the one that actually runs. Your compiler's test suite is responsible for the rest. By the same logic one could also claim that tail recursion optimisation, or loop unrolling are also dangerous because they change the…
I believe there's a Rust RFC for a way to write mandatory tail calls with the become keyword. So then the code is actually defined to have a tail call, if it can't have a tail call it won't compile, if it can have one then that's what you get.
Some languages I was aware of are defined so that if what you wrote could be a tail call it is. However you might write code you thought was a tail call and you were wrong - in such languages it only blows up when it recurses too deep and runs out of stack. AIUI the Rust feature would reject this code.
Re: Why Is SQLite Coded In C
#276Earlier quoted context omitted.
The author cleverly leaves out all the safer alternatives that have existed outside UNIX, and what was happening with computers outside Bell Labs during the 1970's. Not only was Apple was able to launch the Mac Classic with zero lines of C code, their Pascal dialect lives on in Delphi and Free Pascal. As one example.
Isn’t Pascal just as problematic as C in this respect? And the original Mac was mostly (all?) assembly, not Pascal. They couldn’t have used a higher level language anyway. The system was just too small for that. SQLite wouldn’t fit on it.
Not at all, because Pascal is more strongly typed, and has features that C is still yet to acquire in type safety.
Non exaustive list:
- proper strings with bounds checking
- proper arrays with bounds checking
- no pointer decays, you need to be explicit about getting pointers to arrays
- less use cases of implicit conversions, requires more typecasts
- reference parameters reduce the need of pointers
- variant records directly support tags
- enumerations are stronger typed without implicit conversions
- modules with better control what gets exposed
- range types
- set types
- arenas
There was plenty of Pascal code on Mac OS including a Smalltalk like OOP framework, until C++ took over Object Pascal's role at Apple, which again it isn't C.
I love the "but it has used Assembly!" usual rebutal, as if OSes written in C weren't full of Assembly, or inline Assembly and language extensions that certainly aren't C (ISO C proper) either.
If you prefer, Zig is a modern taken on what Modula-2 in 1978, and Object Pascal in the 1980's already offered, with the addition of nullable types and comptime as key differentor in 40 years, packaged in a more appealing syntax for current generations.
Re: Why Is SQLite Coded In C
#277"1. C Is Best"
Re: Why Is SQLite Coded In C
#278I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…
And, in fact, these implementations exist. At least in Rust, there's rqlite and turso.
rqlite[1] author here. Just to be clear, rqlite is not SQLite but rewritten in Go. rqlite uses the vanilla C code, and calls it from Go[2]. I consider that an important advantage over other approaches -- rqlite gets all the benefits of rock-solid[3] SQLite. As result there are no questions about the quality of the database engine.
Re: Why Is SQLite Coded In C
#279> 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. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.
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…
Bound checks are usually conditionally compiled. That's more a kind of "contract" you'll verify during testing. In the end the software actually used will not check anything.
#ifdef CONTRACTS
if (i >= array_length) panic("index out of bounds")
#endifRe: Why Is SQLite Coded In C
#280Earlier quoted context omitted.
Isn’t Pascal just as problematic as C in this respect? And the original Mac was mostly (all?) assembly, not Pascal. They couldn’t have used a higher level language anyway. The system was just too small for that. SQLite wouldn’t fit on it.
Not at all, because Pascal is more strongly typed, and has features that C is still yet to acquire in type safety. Non exaustive list: - proper strings with bounds checking - proper arrays with bounds checking - no pointer decays, you need to be explicit about getting pointers to arrays - less use cases of implicit conversions, requires more typecasts - reference parameters reduce the need of pointers - variant recor…
My point is that the original Mac used little to no Pascal. The assembly isn’t a “rebuttal,” it’s just what was actually used.