Death to C, ++

The C programming language is terrible. I mean, magnificent,
too. Much of the world in which we live was built atop C. It is
foundational to almost all computer programming, both
historically and practically; there’s a reason that the
curriculum for Xavier Niel’s revolutionary “42” schools begins
with students learning how to rewrite standard C library
functions from scratch. But C is no longer suitable for this
world which C has built.

I mean “terrible” in the “awe-inspiring dread” sense more than
the “bad” sense. C has become a monster. It gives its users far
too much artillery with which to shoot their feet off. Copious
experience has taught us all, the hard way, that it is very
difficult, verging on “basically impossible,” to write
extensive amounts of C code that is not riddled with security
holes. As I wrote two years ago, in my
first Death To C piece

In principle, as software evolves and grows more mature,
security exploits should grow ever more baroque … But this is
not the case for software written in C/C++. Buffer overflows
and dangling pointers lead to catastrophic security holes,
again and again and again, just like yesteryear, just like
all the years of yore.

We cannot afford its gargantuan, gaping security blind spots
any more. It’s long past time to retire and replace it with
another language. The trouble is, most modern languages don’t
even try to replace C. […] They’re not good at the thing C
does best: getting down to the bare metal and working at mach

If you’re a developer you already know where I’m going, of
course: to tout the virtues of Rust, which is, in fact,
a viable C/C++ replacement. Two years ago I suggested that
people start writing new low-level coding projects in Rust
instead of C. The first rule of holes, after all, is to stop

Today I am seriously suggesting that when engineers refactor
existing C code, especially parsers and other input handlers,
they replace it — slowly, bit by bit — with Rust. Per this

excellent Geoffroy Couprie post

We have to do something. We must make our software
foundations stronger. That means fixing operating systems,
drivers, libraries, command line tools, servers, everything.
We might not be able to fix most of it today, or the next
year, but maybe 10 years from now the situation will have

Unfortunately, we cannot rewrite everything. […] What I’m
advocating for is much simpler: surgically replace weaker
parts but keep most of the project intact. […] You can
actually take a piece of C code inside an existing project,
import the C structures and functions to access them from
Rust, rewrite the code in Rust, export the functions and
structures from Rust, compile it and link it with the rest of
the project.

Rust is no a panacea, of course, There are many other valuable
approaches to improving software stability and security.
, for instance, or the Langsec movement.) But it is a
plausible and valuable iterative approach, and we are only
going to dig ourselves out of our giant collective security
hole iteratively, one shovelful of better code and better
tooling at a time. The sooner we start digging, the sooner C
will slowly oxidize away.

Leave a Reply

%d bloggers like this: