The Fil-C Manifesto: Garbage In, Memory Safety Out | Hacker News Reader

The Fil-C Manifesto: Garbage In, Memory Safety Out

github.com

13 pointsJarred17 comments

It’s interesting to see a very pragmatic approach towards “better C”. There’s so many “better C” languages out there gaining popular interest like Zig, Hare, Odin, Jai; but none (I don’t consider Rust a better c) try to tackle memory safety, even when stating from a clean slate. Then there’s this thing, which is still mostly normal C, so it’s very easy to apply to existing code, and it does solve memory safety head on.

It’s not clear from reading but it seems like most checks happen at run time, and not at compile time. How much feedback goes the compiler give to the user about mistakes?

Basically all feedback is at runtime.

I’m curious if you’ve looked at the prior attempts at memory safe variants of C or compiler-assisted safety for legacy C? They are really safe with better performance than Fil-C is. More important, you might find some of their ideas useful in your own work.

Here’s a few I remember:

CCured https://people.eecs.berkeley.edu/~necula/Papers/ccured_topla...

Softbound + CETS https://people.cs.rutgers.edu/~sn349/softbound/

Clay Systems Language https://www.eg.bucknell.edu/~lwittie/research.html

Cyclone Language (Rust drew on it) https://en.m.wikipedia.org/wiki/Cyclone_(programming_languag...

Fail-Safe C https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html

CheckedC https://github.com/microsoft/checkedc

Also, one can combine subsets of C with FOSS, static analyzers that can handle those subsets. Then, compose only in ways that the tools can handle. Then, combinatorial and fuzz testing of the interface composition.

I know you’re doing the project for fun while exploring specific ways to achieve your goals. So, these are just some links and concepts that might help on your journey. Lots of folks don’t know about prior work in this area. So, I keep passing it on.

I know about all of them. CCured, Softbound, and Cyclone are abandonware. Cyclone and CheckedC require lots more changes to your code than Fil-C. CheckedC isn't even memory-safe since all it handles are bounds.

Thanks for the super sweet attempt to teach me about this field, but I'm an expert on this stuff already.

The fact that I'm starting from a "no premature opts" mindset and just being full-on pragmatic is because I know better than any of those folks. :-)

The performance loss was many times higher than experts usually hit even when optimizing for correctness. You also assume it will be later be close to C’s performance which most people who are experts wouldn’t claim. I’m glad you are aware of their work, though.

“Know better than any of those folks”

The Word of God says pride comes before the fall and the proud get humbled. If you have the knowledge, then wisdom might be the next thing to add to the project. You will be living pleasing to God and might draw in others with exactly the ideas you need.

I'm an atheist.

So was I. Then, I saw a miracle that disproved all that. I was a highly-arrogant person, too. Turns out Jesus is God, we will all face His judgement, and repenting in the best thing we can do.

God made it easy on us, though. He said anyone who humbly reads His Word will, by supernatural action, know it’s true. He also provided proof. Please do look at GetHisWord.com for both. You’ll get to meet the Creator who made you and all the interesting things you love.

sometimes people really are experts, OP built JavaScriptCore/Webkit for 10 years (and wrote many fun blog posts thx phil), and seems to be working on the ideas in this "joke project" for a few years, the allocator for isoheaping shipped in webkit in 2022 https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...

That could be true. It’s a huge field, though, with many experts on interpreters or even QA not hearing of the tools I mentioned. Industry, FOSS, and academia are often silo’s to various degrees. Perhaps he’s well studied and that would be great.

What caught my eye in his replies on Lobste.rs and here is how he replies. There seems to be as much ego as technical decisions driving it. In that case, people arguing technical details are wasting time since the project needs something else. Or they should thank him and fork it if they have different ideas.

There is a time and place for modesty and humility.

For me, this ain't it, because I know how to solve this problem better than others have done, and so: I'm going to talk about why I think I'm right and I'm going to keep implementing Fil-C.

No need to be offended by the fact that I'm calling my shot!

It can run CURL!!! And OpenSSL! This seems possibly like a big deal.

>Fil-C is currently about 200x slower than legacy C according to my tests

It sure is! :-)

But it can run real code, and that's what matters most in early bringup.

How much faster do you think it can get?

BTW, awesome work!

If enough effort goes into it? Pretty much as fast as C.

Damn, I hope that day will come!

Commits messages are the shit.

Reply on news.ycombinator.com