SoylentNews is people
SoylentNews
It's memory-safe, with a few caveats:
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.
[...] 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 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."
(Score: 3, Insightful) by Rich on Thursday November 21, @04:58PM
Indeed. I think the USP for it is "zero cost for using". I looked around whether it's possible to still use "free", but in a way that just marks a block until the collector sweeps it up, and until then, it would trip any inappropriate use. This would allow running your development on FilC and revert to standard when shipping source. Relying on the collector would make it one-way.
The guy has his head full of garbage collection knowledge, and the collector that comes with FilC seems to be peak state of the art. Where C matters most these days, in kernel drivers, and embedded, such a collector would usually be too heavy to be brought in, both from memory and threading requirements. But for a desktop C++ application, it seems to be a really good thing. Definitely worth keeping an eye on, especially where Valgrind is not an option (e.g. recent macOS).
I've had my own thoughts on how to deal with these C shortcomings, and it would be possible to offer a debug mode that keeps every pointer as unique ID, plus offset. The ID points into a hash table, if it isn't there, it's use-after-free. If it's there, it gets the base address and does a range check. That'd be slower than his approach (and therefore not really low-level production grade), but it'd be way faster than Valgrind, and probably even faster than anything Python.
We've got to accept that all this comes from his GC experience, and is centered around it, and for free, both in investment and development overhead, it's not a bad offering at all.
My own approach would work up from eliminating all "undefined behavior" situations (which is a larger scope than his memory safety) and require worse changes that break source compatibility to some extent, making it much less appealing to a wider audience. For memory safety, I'd use atomic ref counting (tiny constant-time overhead suitable for real-time) and handwave away the "it won't catch cycles" objection with the argument that the halting problem for execution cycles can't be solved, so why should we solve it for memory. I'd just offer a cycle catcher as debug tool. I guess that'd end up halfway between C and Vala (which I think is a very good language, just without the marketing support of whining academic pussies from the US).