4 ms·
The issue with Fil-C is that it's runtime memory safety. You can still write memory-unsafe code, just now it is guaranteed to crash rather than being a potentia
by omcnoe 6mo ago
The issue with Fil-C is that it's runtime memory safety. You can still write memory-unsafe code, just now it is guaranteed to crash rather than being a potential vulnerability.
Guaranteed memory safety at compile time is clearly the better approach when you care about programs that are both functionally correct and memory safe. If I'm writing something that takes untrusted user input like a web API memory safety issues still end up as denial-of-service vulns. That's better, but it's still not great.
Not to disparage the Fil-C work, but the runtime approach has limitations.
- boredatoms 6mo agoFor some things the just-crash is ok, like cli usage of curl
- pizlonator 6mo ago> write memory-unsafe code, just now it is guaranteed to crash If it's guaranteed to crash, then it's memory-safe. If you dislike that definition, then no mainstream language is memory-safe, since they all use crashes to handle out of bounds array accesses
- omcnoe 6mo agoI don't think that's a useful way of thinking about memory-safety - a C compiler that compiles any C program to `main { exit(-1); }` is completely memory-safe. It's easy to design a memory-safe language/compiler, the question is what compromises are being made to achieve it. Other languages have runtime exceptions on out-of-bounds access, Fil-C has unrecoverable crashes. This makes it pretty unsuitable to a lot of use cases. In Go or Java (arbitrary examples) I can write a web service full of unsafe out-of-bounds array reads, any exception/panic raised is scoped to the specific malformed request and doesn't affect the overall process. A design that's impossible in Fil-C.
- wakawaka28 6mo agoI don't think runtime error handling is impossible in Fil-C, at least in theory. But the use cases for that are fairly limited. Most errors like this are not anticipated, and if you did encounter them then there's little or nothing you can do useful in response. Furthermore, runtime handling to continue means code changes, thus coupling to the runtime environment. All of these things are bad. It is usually acceptable to fail fast and restart, or at least report the error.
- pizlonator 6mo agoI could have made Fil-C’s panic be a C++ exception if I had thought that it was a good idea. And then you could catch it if that’s what tickled your pickle I just don’t like that design. It’s a matter of taste
- wakawaka28 6mo agoThat's actually not a bad idea, since apparently it can be used for whole operating systems. But certainly, if you started doing that, any code using the exception would need to be exclusive to Fil-C to benefit from that.
- dzaima 6mo agoThen you run into the problem of infinite loops, which nothing can prevent (sans `main { exit(-1); }` or other forms of losing turing-completeness), and are worse than crashes - at least on crashes you can quickly restart the program (something something erlang). try-catch isn't a particularly complete solution either if you have any code outside of it (at the very least, the catch arm) or if data can get preserved across iterations that can easily get messed up if left half-updated (say, caches, poisoned mutexes, stuck-borrowed refcells) so you'll likely want a full restart to work well too, and might even prefer it sometimes.
- wren6991 6mo agoYou need to distinguish safety properties from liveness properties.
- 100ms 6mo agoWhat's the alternative? https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=ab648af31586d776004fd9296e276106 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- zamadatix 6mo ago.get() will bounds check and the compiler will optimize that away if it can prove safety at compile time. That leaves you 3 options made available in Rust: - Explicitly unsafe - Runtime crash - Runtime crash w/ compile time avoidence when possible
- omcnoe 6mo agohttps://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1f4a6572ff4691a4321b4f5167316905 https://play.rust-lang.org/?version=stable&mode=debug&editio... Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.
- wakawaka28 6mo agoSeems like a niche use case. If it needs code to handle, it's also not apples to apples...
- omcnoe 6mo agoIt's an apple to non-existent-apple comparison. Fil-C can't handle it even with extra code because Fil-C provides no recovery mechanism. I also don't think it's that niche a use case. It's one encountered by every web server or web client (scope exception to single connection/request). Or anything involving batch processing, something like "extract the text from these 10k PDFs on disk".
- wakawaka28 6mo agoSure, it's not implemented in Fil-C because it is very new and the point of it is to improve things without extensive rewrites. Generally, I think one could want to recover from errors. But error recovery is something that needs to be designed in. You probably don't want to catch all errors, even in a loop handling requests for an application. If your application isn't designed to handle the same kinds of memory access issues as we're talking about here, the whole thing turns into non-existent-apples to non-existent-apples lol.
- forrestthewoods 6mo agoRust also has run-time crash checks in the form of run-time array bounds checks that panic. So let us not pretend that Rust strictly catches everything at compile-time. It’s true that, assuming all things equal, compile-time checks are better than run-time. I love Rust. But Rust is only practical for a subset of correct programs. Rust is terrible for things like games where Rust simply can not prove at compile-time that usage is correct. And inability to prove correctness does NOT imply incorrectness. I love Rust. I use it as much as I can. But it’s not the one true solution to all things.
- omcnoe 6mo agoNot trying to be a Rust advocate and I actually don't work in it personally. But Rust provides both checked alternatives to indexed reads/writes (compile time safe returning Option<_>), and an exception recovery mechanism for out-of-bounds unsafe read/write. Fil-C only has one choice which is "crash immediately".
- uecker 6mo agoWhat makes you think that one can not add an explicit bound check in C?
- omcnoe 6mo agoIf you can correctly add all the required explicit bounds checks in C what do you need Fil-C for?
- uecker 6mo agoFor temporal memory safety.
- kimixa 6mo agoSame reason any turing complete language needs any constructs - to help the programmer and identify/block "unsafe" constructs. Programming languages have always been more about what they don't let you do rather than what they do - and where that lies on the spectrum of blocking "Possibly Valid" constructs vs "Possibly Invalid".
- ori_b 6mo agoBy that token, Rust is also memory unsafe: array bounds checks and stack overflow are runtime checks.
- DetroitThrow 6mo agoThere are several ways to safely provide array bounds check hints to the Rust compiler, in-fact there's a whole cookbook. But for many cases, yep, runtime check.
- p1necone 6mo agoWhy are you talking like this is black and white? Many things being compile time checkable is better than no things being compile time checkable. The existence of some thing in rust that can only be checked at runtime does not somehow make all the compile time checks that are possible irrelevant. (Also I think the commenter you're replying to just worded their comment innacurately, code that crashes instead of violating memory safety is memory safe, a compilation error would just have been more useful than a runtime crash in most cases)