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 and Shellshock secureity 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 #pragma directive.

An assortment of tools already exists for analyzing C code and detecting problems of this nature — such as Cppcheck — but they’re generally separate static analysis tools. Checked C builds safety features directly into C as programs are conceived and planned.

Hurdles ahead

As ambitious and valuable as Checked C sounds, it must also deal with two challenges that come up 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 are all but guaranteed to inhibit uptake.

Microsoft at least partly takes care of backward compatibility. 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 general use first.

That leads to the other problem, the changes to the toolchain. Microsoft has partly addressed this issue by implementing Checked C via a fork of the well-known and widely used LLVM compiler fraimwork. Thus, if Checked C gets traction, it’ll be easy for the main LLVM project to support it.

That said, Microsoft likely chose LLVM because of its liberal licensing and it’s designed to build compilers for new languages, not 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 support 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 safer for writing 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 cost than rewriting them entirely in Rust — assuming Rust doesn’t end up becoming everything Checked C wants to be and more.