Microsoft has open sourced a research project called Checked C to add new syntax and typing to the C language. The primary goal is to neutralize some hazards of C programming, such as the bugs that gave rise to the Heartbleed andShellshock security incidents.
It’s a bold idea, at least on paper. The tough part will be finding a way to provide incentive for C developers to change existing code — a task the legacy weight of C has always made difficult.
Check yourself before you wreck yourself
Checked C is a modified version of C that addresses the issues that arise with pointers, C’s mechanism for accessing memory directly. The language provides several new kinds of pointer and array types that come with built-in safeguards. They’re distinct from the existing unsafe pointer types in C, so a programmer can use the new, checked pointer types for safety and revert back to the unsafe types if that’s ever required.
The new version also provides checked program scopes. These are blocks of the program code where bounds checking is turned on by default. If the programmer attempts to use an unchecked pointer within such a scope, the compiler will reject it. It’s also possible to specify that a whole program be checked by default, by way of a compiler
An assortment of tools already exists for analyzing C code and detecting problems of this nature — e.g., Cppcheck — but they’re generally separate static analysis tools. Checked C builds safety features directly into C as part of the way programs are conceived and planned.
Ambitious and valuable as Checked C sounds, it must also deal with two challenges that arise whenever changes are suggested to any existing language. The first is that such changes are typically not backward-compatible. Second, they sometimes involve disruptive changes to the toolchain. Both of these are all but guaranteed to inhibit uptake.
Microsoft has the backward compatibility issue at least partly taken care of. The changes introduced by Checked C don’t invalidate existing C programs; they still compile as-is. All of the new syntax and alterations to the language co-exist with its legacy incarnation.
An existing C program doesn’t even need to be converted to Checked C all at once; it can be converted file-by-file or function-by-function. Microsoft also claims the new-style checked constructions are "layout-compatible with existing pointer and array types." This high degree of backward and forward compatibility gives Checked C an advantage, but again, not an automatic win, as the language still has to pass into something like general use first.
That leads to the other problem, the changes to the toolchain. Microsoft has at least partly addressed this issue by implementing Checked C via a fork of the well-known and widely used LLVM compiler framework. This way, if Checked C gets traction, it’ll be easy for the main LLVM project to support it.
That said, it’s likely Microsoft chose LLVM because of its liberal licensing and because it’s designed to build compilers for new languages, rather than because it served as a vehicle to get Checked C into many hands. The older and more widely used GCC compiler would also need to provide support for Checked C for it to enjoy greater uptake. (It goes without saying that Microsoft would likely add such support to Visual Studio if the demand manifested.)
Mozilla’s Rust language has been positioned as a safer way to write the types of programs normally left to C . There’s little question the language has enjoyed great advances in its development and has a thriving audience . But it’s still young, while C is widely and deeply entrenched. Modifying existing C apps might come at less of a nest cost than rewriting them entirely in Rust — assuming, that is, Rust doesn’t end up becoming everything Checked C wants to be and then some.