Developers looking to continue working in the C and C++ programming languages amid the global push to promote memory-safe programming now have another option that doesn’t involve learning Rust.
Filip Pizlo, senior director of language engineering at Epic Games, has created his own memory-safe flavor of C and – because why not? – named it after himself.
Pizlo got in touch after seeing our report on TrapC – a memory-safe C-fork due for release next year.
“I wanted to alert you to the existence of Fil-C, a personal project of mine, which exists today, does just about everything TrapC claims to do (including being totally memory-safe), and is freely available,” Pizlo explained. “It aims for 100 percent compatibility with C and C++ – just compile your stuff with my compiler and you get memory safety.”
The US government and other interested parties are rather keen to encourage memory safety – something not available out of the box for C and C++ code. C and C++ require manual memory management, which has been shown to be inadequate for preventing memory safety bugs like out of bounds reads and writes.
Since the majority of serious vulnerabilities in large codebases can be attributed to memory safety failings, the common refrain over the past few years has been to develop in a programming language like Rust that (optionally) produces memory-safe code. And more recently there have been efforts to rewrite legacy code in critical libraries and applications using Rust.
There are many other memory-safe languages – such as C#, Java, Python, Swift, Go, and JavaScript. But Rust, for better or worse, has become the most commonly cited option in memory safety evangelism because it’s fast, suited for low-level code, and does a lot of things well (safe concurrency and a well-conceived package management system). What’s more, the non-profit Rust Foundation has been run well enough to attract funding and support from the tech firms likely to be interested in Rust’s qualities.
Also, Rust came out of Mozilla, which isn’t seen by the major tech platforms – several of which have their own home-grown programming languages – as a competitor. Consider that Rust debuted in late 2013 and Apple’s Swift arrived a year later – during that period, Rust has attracted a broad constituency, while Swift is mainly used by Apple-aligned developers.
But the thing about Rust is that it’s not all that easy to learn. So calls to rewrite everything in Rust have elicited pushback from those with significant C or C++ experience – like Linux kernel maintainers, who would prefer to continue working in languages they’ve mastered.
Like the forthcoming TrapC fork and the Safe C++ project, Fil-C aims to support memory safety without requiring reeducation in another programming language.
Pizlo, who introduced Fil-C at the Splash 2024 conference [VIDEO] last month, explains his motivation in the project repo.
In my spare time, I decided to make my own memory-safe C and C++. This is a personal project and an expression of my love for C
“The C and C++ programming languages are wonderful,” he said. “There is a ton of amazing code written in both of them. But C and C++ are unsafe languages. Simple logic errors may result in an attacker controlling where a pointer points and what is written into it, which leads to an easy path to exploitation. Lots of other languages (Rust, Java, Haskell, even JavaScript) don’t have this problem!
“But I love C. And I love C++ almost as much. I grew up on them. It’s such a joy for me to use both of them! Therefore, in my spare time, I decided to make my own memory-safe C and C++. This is a personal project and an expression of my love for C.”
Epic Games owns the copyright for Fil-C but, according to Pizlo, all its components are permissively licensed open source – the compiler bits are Apache2 and the runtime bits are BSD.
Fil-C has some limitations. Presently, it only works on Linux/x86_64. Also, it’s slow – about 1.5x-5x slower than legacy C. That’s in part because of its implementation of a pointer encoding method for tracking bounds and types called MonoCaps, and also overhead from calling conventions and dynamic linking that differ from standard C.
“The plan to make Fil-C fast is to fix these issues,” explains Pizlo. “I believe that fixing these issues can get Fil-C to be only 1.5x slower than C in the worst cases, with lots of programs being only 1.2x slower. But it’ll take some focused compiler/runtime/GC hacking to get there.”
Fil-C also isn’t aiming for full Application Binary Interface (ABI) compatibility with what Pizlo calls “Yolo-C/C++” – normal C/C++.
“If I had ABI compatibility with [Yolo-C/C++] then it would incentivize me and other users to say, ‘okay I’m going to recompile this file with Fil-C, link it to a whole bunch of files that are normal C because I don’t want to be bothered with porting them, and then what you’ll get as a result is a program that is not memory-safe,” he explains.
Part of the reason why I’m doing this is I want to obviate the need for Rust
Presently, some C programs can be compiled with Fil-C without any changes, including bzip2, zip, pcre, and ncurses. Other code – such as CPython, SQLite, Lua, OpenSSH, Lynx, libc++abi/libc++, jpeg6b, zsh, musl, xzutils, and simdutf – will work with small changes.
Pizlo observes in his presentation that while there have been substantially successful attempts to make C code memory-safe – such as CheckedC and -fbounds-safety – many of these fall short in one way or another, particularly for certain edge cases.
His goal, he says, is to support garbage in, and memory safety out.
“Part of the reason why I’m doing this is I want to obviate the need for Rust,” declares Pizlo. “I’m not there yet performance-wise, but I will get there.” ®