Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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
  • > [...] 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
  • 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.
    by QuaternionsBhop
  • 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 :-)

    https://clang.llvm.org/docs/BoundsSafety.html#overview

    by KateLawson
  • 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.

    https://news.ycombinator.com/item?id=49284966

    by hechang1997
  • 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
  • There is a solution that Mozilla uses in prod for legacy C codecs:

    https://rlbox.dev/

    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
  • Why isn't fil-C ABI compatible with C?

    https://fil-c.org/runtime

    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

Explore Birbla archives