Memory safe languages are a good thing. So more of those is obviously a good thing too.
And it is pretty attractive. Compare 'rewriting sudo in rust as sudo-rs took 2 years' with 'recompile sudo with fil-c took 5 minutes'. Both claim to be memory safe (fil-c even claims to not need any unsafe hatches).
If fil-c works as promised, it is a really neat way to get memory safety for existing C/C++ codebases for minimal effort and avoid the rust vs C war scenes.
Sure. But thats the same for all other memory-safe languages too.
Once you hand the keys to your memory kingdom to some external untrusted library, it can mess around with your memory. Thats a feature. So unless your OS has ways to protect your process memory during a function call, there is not much you can do. And if you'r OS does that, you basically add another kernel-userspace style barrier somewhere (as the kernel can protect it's memory from userspace obviously).
The problem is that anything calling out to what is effectively an FFI call, or anything that has memory side effects at all, has to be wrapped. You call an external function that returns a pointer? You have to wrap it.
It's not a drop-in replacement for many large projects.
Sure, but neither is Rust, which has similar issues.
And if you go for a full memory safe userland, like it is demonstrated here (e.g. recompiling libc and lots of base libs), you basically can do it, if you want.
It still is far less effort to wrap a few FFI/external calls or migrate the libs too, then it is to rewrite them in a totally different language. Of course, the bigger the project, the more portable it has to be and the more external binary code blobs you have to work with, the harder it gets.
Or if you are working on things like I am, where you have a JIT and generated code. Not impossible to make work, but the JIT would have to understand Fil-C's ABI. That'd be a large undertaking.
BlueGoliath@reddit
Why is this getting pushed so hard.
schlenk@reddit
Memory safe languages are a good thing. So more of those is obviously a good thing too.
And it is pretty attractive. Compare 'rewriting sudo in rust as sudo-rs took 2 years' with 'recompile sudo with fil-c took 5 minutes'. Both claim to be memory safe (fil-c even claims to not need any unsafe hatches).
If fil-c works as promised, it is a really neat way to get memory safety for existing C/C++ codebases for minimal effort and avoid the rust vs C war scenes.
BlueGoliath@reddit
The moment you call into other code not compiled using Fill-C is the moment memory safety goes out the window.
rereengaged_crayon@reddit
fil-c is not ABI compatible with non-fil-c compiled code
schlenk@reddit
Sure. But thats the same for all other memory-safe languages too.
Once you hand the keys to your memory kingdom to some external untrusted library, it can mess around with your memory. Thats a feature. So unless your OS has ways to protect your process memory during a function call, there is not much you can do. And if you'r OS does that, you basically add another kernel-userspace style barrier somewhere (as the kernel can protect it's memory from userspace obviously).
If you don't want it, don't use it.
Ameisen@reddit
The problem is that anything calling out to what is effectively an FFI call, or anything that has memory side effects at all, has to be wrapped. You call an external function that returns a pointer? You have to wrap it.
It's not a drop-in replacement for many large projects.
schlenk@reddit
Sure, but neither is Rust, which has similar issues.
And if you go for a full memory safe userland, like it is demonstrated here (e.g. recompiling libc and lots of base libs), you basically can do it, if you want.
It still is far less effort to wrap a few FFI/external calls or migrate the libs too, then it is to rewrite them in a totally different language. Of course, the bigger the project, the more portable it has to be and the more external binary code blobs you have to work with, the harder it gets.
Ameisen@reddit
Or if you are working on things like I am, where you have a JIT and generated code. Not impossible to make work, but the JIT would have to understand Fil-C's ABI. That'd be a large undertaking.
orangejake@reddit
it also has large perf overheads (I've heard 2x memory, up to 4x compute, but that's just in random internet comments).
fiskfisk@reddit (OP)
As someone who didn't know about Fil-C I found it interesting. Not really about pushing something.
chucker23n@reddit
Previous discussion: https://reddit.com/r/programming/comments/1obwnkm/filc_is_a_fanatically_compatible_memorysafe/