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 speed.

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 digging.


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.

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 improved.

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. (Formal verification, 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.

Source: Business Insider.

More@ https://www.technapping.com