It's memory-safe, with a few caveats [theregister.com]:
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 [theregister.com] – a memory-safe C-fork due for release next year.
"I wanted to alert you to the existence of Fil-C [github.com], 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 [memorysafety.org] 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 [github.io]. 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.
[...] 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."
[...] Pizlo observes in his presentation that while there have been substantially successful attempts to make C code memory-safe – such as CheckedC [github.com] and -fbounds-safety [llvm.org] – 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 [youtube.com] Pizlo. "I'm not there yet performance-wise, but I will get there."