[Too]

Can someone give a tldr of what makes fil-c different from just compiling with clang’s address sanitizer?

Calling it memory safe is a bit of a stretch when all it does is convert memory errors to runtime panics, or am I missing something? I mean, that’s still good, just less than I’d expect given the recent hype of fil-c being the savior for making C a competitive language again.

[integralid]

ASan does not make your code memory safe! It is quite good at catching unintentional bugs/oob memory writes in your code, and it is quite reliable (authors claim no false positives), but it has false negatives i.e. won't detect everything. Especially if you're against someone who tries to corrupt your memory intentionally.

ASan works by (simplifying a lot) padding allocations and surrounding them with untouchable "red zone". So with some luck even this can work:

  char *a = new char[100];
  char *b = new char[1000];
  a[500] = 0; // may end up in b

[pizlonator]

Address sanitizer won’t panic/crash your program on all memory safety violations. Attackers know how to achieve remote code execution in processes running Asan. Asan’s docs specifically call out that you should not use it in prod. In other words, Asan is not memory safe. It’s just a bug finding tool.

Fil-C will panic your program, or give some kind of memory safe outcome (that is of no use to the attacker) in all of the cases that attackers use to achieve remote code execution. In other words, Fil-C is memory safe.

The fact that Fil-C achieves memory safety using runtime checks doesn’t make it any less memory safe. Even rust uses runtime checks (most importantly for array bounds). And, type systems that try to prove safety statically often amount to forcing the programmer to write the checks themselves.

[procaryote]

If you can rely on memory errors panicing before the memory error can have an effect, you're memory safe. Memory safety doesn't require "can't crash".

[seabrookmx]

Exactly. Or Rust wouldn't be memory safe due to the existence of unwrap().

Not that crashing can't be bad, as we saw recently with Cloudflare's recent unwrap-based incident.

[brabel]

Even without unwrap, Rust could still crash on array out of bounds access. And probably more similar cases.

[Too]

From a definition point of view that might be right and it’s no doubt a good step up, compared to continuing with tainted data. In practice though, that is still not enough, these days we should expect higher degree of confidence from our code before it’s run. Especially with the mountains of code that LLMs will pour over us.

[procaryote]

It's a nice ambition, but it's a different thing than memory safety