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.

▲

pizlonator 3 hours ago | parent | next [-]

> 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 3 hours ago | parent [-]

I 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.

▲

dzaima 3 hours ago | parent | next [-]

Then 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.

▲

wakawaka28 3 hours ago | parent | prev [-]

I 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 2 hours ago \| parent [-]
		I 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

▲

ori_b 3 hours ago | parent | prev | next [-]

By that token, Rust is also memory unsafe: array bounds checks and stack overflow are runtime checks.

	▲	p1necone 2 hours ago \| parent \| next [-]
		Why 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)
	▲	DetroitThrow 3 hours ago \| parent \| prev [-]
		There 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.

▲

100ms 3 hours ago | parent | prev | next [-]

What's the alternative?

https://play.rust-lang.org/?version=stable&mode=debug&editio...

▲

zamadatix 3 hours ago | parent | next [-]

.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 3 hours ago | parent | prev [-]

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.

▲

uecker 2 hours ago | parent | next [-]

I do not know how Fil-C handles this, but it could raise a signal that one can then catch.

▲

wakawaka28 3 hours ago | parent | prev [-]

Seems like a niche use case. If it needs code to handle, it's also not apples to apples...

▲

omcnoe 3 hours ago | parent [-]

It'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 2 hours ago \| parent [-]
		Sure, 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.

▲

boredatoms 4 hours ago | parent | prev | next [-]

For some things the just-crash is ok, like cli usage of curl

▲

forrestthewoods 3 hours ago | parent | prev [-]

Rust 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 3 hours ago | parent | next [-]

Not 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 2 hours ago | parent [-]

What makes you think that one can not add an explicit bound check in C?

▲

tialaramex 2 hours ago | parent | next [-]

It's trickier than it looks because C has mutable aliases. So, in C our bounds check might itself be a data race! Make sure you cope

	▲	uecker an hour ago \| parent [-]
		Depending on what you are doing, yes. But the statement I responded to "your only choice is crash" is certainly wrong.

▲

omcnoe 2 hours ago | parent | prev [-]

If you can correctly add all the required explicit bounds checks in C what do you need Fil-C for?

	▲	kimixa 43 minutes ago \| parent \| next [-]
		Same 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".
	▲	uecker an hour ago \| parent \| prev [-]
		For temporal memory safety.

▲

wakawaka28 3 hours ago | parent | prev [-]

>And inability to prove correctness does NOT imply incorrectness.

And inability to prove incorrectness does NOT imply correctness. I think most Rust users don't understand either, because of the hype.