3 ms·

Why isn't fil-C ABI compatible with C? https://fil-c.org/runtime https://fil-c.org/runtime Apparently this was done intentionally. The rationale given is that

by andai 3mo ago

Why isn't fil-C ABI compatible with C? https://fil-c.org/runtime 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?

Georgelemental 3mo ago
It's also because Fil-C calls need to carry along a bunch of extra information, to support the safety checks
- sheepscreek 3mo ago
  Yes and AFAIK any fil-C program needs to be linked against fil-C compiled libraries, such as libc/musl/etc. I too would like to know what other challenges exist in making this process more automated.
  - ameliaquining 3mo ago
    What precisely do you mean by "this process"? The kind of linking that Fil-C supports is pretty different from what the blog post proposes.
- pizlonator 3mo ago
  Correct
ameliaquining 3mo ago
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.
deleted 3mo ago
[deleted]

by andai 3mo ago

Georgelemental 3mo ago

It's also because Fil-C calls need to carry along a bunch of extra information, to support the safety checks

sheepscreek 3mo ago
Yes and AFAIK any fil-C program needs to be linked against fil-C compiled libraries, such as libc/musl/etc. I too would like to know what other challenges exist in making this process more automated.
- ameliaquining 3mo ago
  What precisely do you mean by "this process"? The kind of linking that Fil-C supports is pretty different from what the blog post proposes.
pizlonator 3mo ago
Correct

ameliaquining 3mo ago

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.

deleted 3mo ago

[deleted]