Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Reading this my slop-sense is tingling.by nnevatie
- Bullshit. Domen is super legit and an incredible dev. I use his tools daily and nothing he does can be described as slopby nylonstrung
- (revised comment)
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.
by chubot - LLM-written post, but I think the core idea is okay. I would advocate for more opportunities for safety, even if some of the safety is runtime safety rather than "only" Rust's borrow checker.by LoganDark
- This doesn't look like LLM slop to me, or even LLM generated.by cpburns2009
- > [...] instead of accidentally linking ordinary C into it
Out of curiosity. If you really needed to, could a language speak both the C ABI and the Fil-C ABI? As I understand Fil-C itself can't do this without having Python-like FFI overhead, but maybe a different compiler implementation could?
by creatonez - Wouldn't this abandon the entire premise that fil-c binaries will crash rather than corrupt?
- This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.
- How does it prevent multiple mutable pointers?by inigyou
- Any reason why you don't use clang's `-fbounds-safety`? It offers ABI compatibility and incremental adoption. The author of Fil-C worked on it also :-)by KateLawson
- That is a great feature
But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
by pizlonator - Check this out: https://github.com/IntegralPilot/rustc_codegen_jvm
While this cannot compile C/C++, it can serve as a fil-C alternative for unsafe pure rust code.
by hechang1997 - That's an interesting project, thanks for the link.by erichocean
- Extern "fil-C" can't be compatible with Rust code or something similar. It requires a metadata block attached to each allocation. So, if a memory block has been allocated in Rust and a pointer to it is passed to a fil-C function, it can't access it correctly. The only way to allow such cross-langauge-and-abi calls is to compile Rust code itself like fil-C, which requires doubled memory consumption, expensive runtime checks and GC overhead.by Panzerschrek
- Another way would be to enforce a copy, adding the metadata, at the boundary with fil-C, right? Of course that makes the FFI way less useful...by tracnar
- Why would it double memory consumption just for a metadata block? Why not just wrap the memory allocation function so it makes that block?
- Naah.
Solvable by turning the usual C library allocation pattern inside-out:
Only the C side allocates, Rust gets views of that memory.
Also well established - calling WebAssembly components requires exactly the same pattern, as the only way to malloc is to call into the WASM side.
by jaen - There is a solution that Mozilla uses in prod for legacy C codecs:
It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.
by pornel - Yeah rlbox is great.
Fil-C is more precise than valgrind or asan. Valgrind and asan will allow a buggy access (like an OOB) to succeed if the resulting address is valid at all - which is useless from a security enforcement perspective since clobbering valid addresses is what the attacker is trying to do.
Fil-C only allows an access to succeed if it’s in bounds of that pointer’s capability. That is a useful level of precision for security, since it prevents the attacker from clobbering the addresses of their choice.
by pizlonator - Why isn't fil-C ABI compatible with C?
Apparently this was done intentionally. The rationale given is that we don't want to allow non-safe C to be used in fil-C programs. Fair enough.
But why should we prevent fil-C programs to be used from Rust (or C, for that matter)?
I don't understand much about compilers, but I guess allowing one would also allow the other? i.e. it's not possible to make fil-C ABI compatible with C (so that it can be more easily called), while also not letting you use call C from it?
by andai - It's also because Fil-C calls need to carry along a bunch of extra information, to support the safety checks
- You're looking too much at the complete memory safety goal; the important part here is the interop non-goal. Designing a foreign function interface between Fil-C and regular C, in a way that upholds both languages' expectations about the environment the code's running in, is a very difficult problem and nobody seems to have much of an idea of how such a thing could work.
I worry that this same problem will doom the extern "Fil-C" idea that this post advocates. Zig is not really an encouraging precedent because Zig's proposed memory-safe mode adds runtime checks to everything just like Fil-C does, whereas the post author wants to avoid those checks for Rust code that's already statically known to be memory-safe. That said, it's possible I'm missing something.