Hacker News new | ask | show | jobs
by vodou 1426 days ago
C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.
4 comments

That would explain all the vulnerabilities in systemd and Linux. They just aren't experienced enough. Linus needs to get in touch with an expert.
I’m looking forward to your efforts in rewriting it in Rust
So is everyone else! Can't happen soon enough.
SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed.

It still accumulates CVEs: https://www.sqlite.org/cves.html.

As I recall, one of the advantages of C over Rust is that the SQLite authors have the tooling to do 100% branch coverage testing of the compiled binaries in C. They tried Rust, but Rust inserts code branches they are unable to test.

The tradeoff then is the small number of bug causing the denial of service bugs listed, vs. not having 100% branch coverage. And they chose the latter.

(The authors also believe Rust isn't portable enough, not handles out-of-memory errors well enough - https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a... .)

Are you aware of a way to develop fault free code? Please share this knowledge then, please.
It's easy to develop fault-free code: just redefine all those faults as (undocumented) features!

That's not a helpful answer, but it's basically the same thing you're doing--redefining memory safety vulnerabilities that would be precluded entirely by writing in memory-safe languages as programmer faults.

He's aware of a way to develop memory-corruption-fault free code, obviously.
I guess "experienced C programmers" must be short supply although they have been writing C for years.
The effort is massive and the experience to do so at scale is very rare.