...is entirely justified. While we all go mad for Rust and its steep learning curve, we may have missed the most important thing to happen to C/C++ since they were invented - Fil-C.

I am a C enthusiast. When you want to get close to the machine it is what you need and I don't want abstractions to take me away from the hardware. However, I have to admit that it is very easy to make mistakes that result in difficult-to-find bugs and easy-to-exploit code. Most of the time I am willing to take the risk, but often I resort to the poor practice of writing the code to get it working and promising to go back and "make it safe" later. This is not good and as a result I have been trying to learn to love Rust. I do appreciate Rust, but love is still some way away.

So when I heard about Fil-C I was very interested, but worried about buying into a one-man project that, no matter how good, might waste me time on a project going nowhere. Fil-C is a personal project of Filip Pizlo, a senior director of language engineering at Epic Games. Then I noticed that other people were taking it seriously. In particular, Grayden Hoare, originator of Rust, seems to think it is worth a look. Then it dawned on me that I was being too cautious. Fil-C isn't a new language, it is a C compiler. If I don't like it or it is abandoned, I can just go back to GCC or Clang with very little lost. Some are even suggesting that compiling with Fil-C, finding the problems, fixing them and then compiling with GCC is a good plan.

In this day and age of AI-assistance, it begs the question of why we are allowed to write unsafe C. The C language isn't unavoidably unsafe, it just lacks the safety barriers to stop you from falling into deep holes. There is no reason why we cannot erect some safety barriers, or better safety nets, to catch the errors busy programmers tend to make before code gets out into the real world.

C can be made safe without changing a letter of the language. Fil-C is a compiler that takes standard C/C++ and transforms all unsafe operations into code that dynamically checks for violations of Fil-C's rules.  These rules are mostly about pointers - what else!

What the documentation says is:

Achieving memory safety using a pointer capability model means:

• • Prohibiting accesses that are out of bounds of the object the pointer is allowed to access.

  • Prohibiting accesses to freed objects.

  • Prohibiting writes to readonly data.

  • Prohibiting reads and writes to non-data objects, such as function pointers, or "special" objects internal to the Fil-C runtime (like the innards of threads or jmp_bufs).

  • Prohibiting reads or writes that would corrupt Fil-C's understanding of any pointer's capability, leading to failure to meaningfully enforce any of these rules.

The bit that make me think that this is an above average attempt is the part about prohibiting actions that would corrupt the understanding of the pointer. That is realistic, if not logically satisfying. The second thing that is encouraging is:

"In addition to memory safety, Fil-C's other goal is fanatical compatibility. This means that Fil-C's capability model also has to allow most (or ideally all) "safe" uses of C pointers; that is, idioms that are in widespread use and don't lead to exploitation unless they violate the above rules. This means even supporting uses of pointers that the C spec deems to be undefined behavior. And it means preserving sizeof(T*) to be the same as what you'd expect - i.e. 8 bytes on 64-bit platforms."

I don't know about you, but I tend to use C idioms - I guess they wouldn't make to idiom status if we didn't use them and as we use them they should be respected.

The real shocker is that Fil C uses a garbage collector to keep track of everything - C with a garbage collector, we live in truly amazing times...

The one big point that needs to be made clear is that this is not a static analysis. The actually running code picks up the unsafe behavior and throws an error. This means that you have to run and exercise the code to find out what the problems might be. It looks like a good application of a code coverage tool is needed. 

The system seems to be good enough to compile and run, without much modification, a significant number of well-known programs - Python 3.12.5, make, grep, vim, Emacs, git, perl 5, tcl. sudo, openssl, curl and many more... The cost of all of this is a speed penalty of up to 4x with a mean of about 2x. There is also an increase in memory requirements perhaps as much as 2x. This makes Fil-C less than perfect for IoT and small machines, but you always have the option of doing a final compile with Clang or GCC.

It certainly looks worth a try and it's still being developed - early days. As Filip points out' it could well be: 

"... that the bounds checking Fil-C inserts can make pointer-twiddling C code safer than pointer-twiddling unsafe Rust. "

• Mike James, the editor of I Programmer, is also prolific author. In Deep C Dives: Adventures in C he looks in depth at specific aspects of C that make it a unique language.

More Information

Fil-C

A note on Fil-C

Related Articles

Microsoft Making C Safe - Checked C

The Feds Want Us To Move On From C/C++

DARPA Wants All C Converted To Rust

Is Rust Safe?

Fundamental C - Pointers, Cast & Type Punning

C Undefined Behavior - Depressing and Terrifying (Updated)

Microsoft Open Sources Checked C

Safe C++ Loses Out To Profiles

C++ For The 21st Century

Bjarne Stroustrup Defends C++ As Safe

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info