Related to fil-c ABI proposal: https://codeberg.org/ziglang/zig/issues/36237
38 Likes
Cool talk and cool demo at the end, hopefully this gives people some confidence that it’s truly cool technology!
8 Likes
I wonder when the extra allocations may happen. Filip mentions something being lazy (still having a little difficulty wrapping my head around the invisicaps). For some of my real-time software, I care about when the allocations happen, especially if I am asking the OS for memory. My mental model for syscalls currently just assumes that I should be minimizing them, because I have to assume they may take any amount of time. So I am very careful to not allocate after initialization of my program. Is this possible to accomplish (only allocate when I allocate)? Or must the GC or runtime necessarily require dynamic memory allocation?
Only allocate when I allocate could also have the side benefit of surfacing errors from the OS on out of memory.
1 Like
From how I understand things you probably don’t want to use Fil-C if you have real-time requirements, or at least this specific implementation of the idea.
1 Like
Based on my current understanding, it happens at any point where you allocate a “thing” that might be taken pointer of. So it technically applies even to local variables on stack. However, the compiler needs to do some kind of escape analysis and if it can guarantee that the pointer does not escape beyond the current scope, it can skip that. I think that’s why there is talk that Fil-Zig could be more efficient than Fil-C, because the single unit of compilation makes it easier to reason about the escape analysis.
4 Likes
liked the video solely based on his hair alone
3 Likes
I’m fairly sure one such case is returning a pointer of a local stack value. For that particular one, I’d just as soon treat it as a compiler error and fix my code, but I can see some value in enabling, you know, every line of old buggy C code.
I wouldn’t mind using a GC for some allocations, but you’re right, I would want to know when & where.
Really great talk, he mentions that fil-c should work for any LLVM IR producing language not just C and C++.
Wonder if the first step in tackling the codeberg issue would be to use fil-c’s LLVM fork and see if Zig’s produced LLVM IR is as well behaved with pointers as Clang. That could be a good proof of concept for fil-c + Zig
3 Likes
Also answered one of the questions from the other day, the 4x vs 6x perf hit: he measured a median of 4x and Dr Hipp (of sqlite) measured 6x.
Re: my other answer, I really should have read the whole thread first, sorry to repeat things.
1 Like
One thing I am surprised is the 3rd guy’s question about how many Linux userland programs in his computer were detected as having memory safety issues or bugs… The answer is 0, the only one he mentioned was not really a safety issue…
Although they may not be exhausted during this few days of test, it is still quite a good result. C/C++ programmers handle those well, even with decades of insults and complaints… I take my hat off.
2 Likes
I think this is the expected result since he isn’t actively trying to exploit the software. He didn’t conclude these packages have no bugs relating to memory safety, just that typical usage doesn’t trigger them.
This makes sense because if typical usage read out of bounds or such, then users would be experiencing crashes or otherwise incorrect behavior under typical usage and it would get patched.
It’s likely that many of these packages do contain exploitable bugs relating to memory safety, the cool thing about building them in Fil-C is that it makes these bugs no longer exploitable. I imagine you could fuzz the Fil-C builds and find some interesting stuff.
9 Likes
Not fully.
As many have pointed out: Fil-C finds memory safety bugs across allocations.
But only because something stays inside of an allocation, doesn’t mean that it isn’t a safety problem.
I think we have all heard of the CVEs caused by stack buffer overflows, or intra-struct buffer overflows.
These don’t get caught by Fil-C but are still memory safety problems.
What do you mean, fil-c catches out of bound writes/reads and stack overflows as well? It also catches type confusions.
See the code example here and run it: Purely Technical Discussion: Memory-Safe Compilation Mode Inspired by Fil-C - #36 by KilianHanich
At least when I ran it compiled with the current release of Fil-C, it wasn’t caught.
1 Like
Awesome presentation. I watched it last night.
Straight fire. 67!
It was very cool to see even the tiniest bit under the hood, excited for things to come with Fil-C / Zig!