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: 4, Insightful) by turgid on Tuesday November 19, @09:35PM (7 children)
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.
It has been well known for many decades now (two at least, maybe three even) that rewriting all your code in a different language isn't the answer to all your problems.
There was a famous case well documented where Borland IIRC dropped the ball on its office productivity software (yes, they had a spreadsheet and word processor) proudly announcing the next version would be "all new code." It was late and didn't work and Microsoft Word and Excel cornered the market.
What really matters is understanding software engineering. That means understanding how to design, implement, test and optimise programs in any language. Yes, some languages buy you advantages, but throwing away all your code, unless it is truly dreadful, and starting again is not a good idea.
If you understand the issues, and if you understand your product, and if you have the institutional knowledge and good test harnesses, process and infrastructure, you are 90% of the way there.
I wish I had more time to play with Rust but I keep getting dragged back into the C++ world. I crossed that event horizon and I'm condemned to orbit. I did not rewrite all my C code in C++. I investigated some years ago and concluded it was the wrong way to go. C compilers kept getting better. C++ kept diverging and getting more complicated.
Choose good tools for the language you need to use. Use a good C compiler. Use a good C++ compiler. Yes, use Rust if it suits your purpose. Don't throw away your old working code because of the new fad. You should be able to get code written in different languages to speak to each other. If you can't that's an infrastructure problem.
I don't write shell scripts in C and I don't write C in shell scripts.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by driverless on Wednesday November 20, @02:45AM (2 children)
Microsoft did it too with their attempted Word rewrite (Project Pyramid).
And that's not even getting into the near-infinite number of projects based on "let's rewrite all this old crap in the currently trendy language/methodology/whatever", which invariably fail after burning through tens or hundreds of millions of dollars (did Taligent break the billion-dollar mark?).
(Score: 2) by turgid on Wednesday November 20, @09:21AM (1 child)
Remember the project in 1997 to rewrite Linux in C++ "because reasons?"
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by driverless on Wednesday November 20, @09:37AM
And then just when they'd finished they'd have had to rewrite it all again in C++'98. And then as they were completing that C++'03 came along. And just as they were sitting back it was C++ '11. And then another rewrite for C++'14. And then again for C++'17. And they'd probably still be working on the C++'20 update right now.
Thing is, C++ isn't a goal but a moving target. Which is another argument for C, it's actually pretty stable.
(Score: 2) by bzipitidoo on Wednesday November 20, @05:46AM (3 children)
> but throwing away all your code, unless it is truly dreadful, and starting again is not a good idea.
The developers of Doom disagree with that sentiment. They very much advocate making multiple fresh starts.
(Score: 2) by turgid on Wednesday November 20, @08:02AM (2 children)
So by definition, their code got into a dreadful state, where it was unmaintainable. It became so complex it could no longer be enhanced.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Touché) by janrinok on Wednesday November 20, @09:40AM (1 child)
Or it was written in a language that too few people are willing to support nowadays e.g. Perl?
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 0) by Anonymous Coward on Sunday November 24, @02:39AM