alt Hacker News> If FilPizlonator determined that the inline assembly is not safe, then it'll replace it with a Fil-C panic. That panic will provide diagnostics about why the assembly was rejected.
Most stupid thing I ever heard. If a safety violation is known at compile-time, you error at compile-time. You might never catch it in a test, and there you have the panic at the customer. He will be pleased.
Replies
They acknowledge that it's odd, and give this justification:
"Using runtime panics has the nice property that inline assembly in dead code doesn't get in the way of porting software to Fil-C. Also, it's consistent with how Fil-C usually reports errors."
You have to understand that Fil-C primarily exists as a marketing stunt. Once you do, you'll understand a lot of its technical decisions better. Its definition of "memory safety" involves translating C's semantics into those of a related language with arbitrary but technically defined behavior instead of having UB (for example, under some circumstances Fil-C considers it legal to read a value from a totally different, possibly-inaccessible pointer when dereferencing an unrelated pointer). The justification in all cases is that this is not only better than UB, but better than using a safe systems language that prevents these behaviors to begin with, because it applies at the executable level, while the large slowdown is justified because it allows people to use existing C applications unchanged instead of rewriting in a safe language (never mind that these two claims contradict each other). It's also supposedly better than one of the many solutions for C-in-a-runtime (like wasm, or Graal-C) because instead of using a hardened runtime that actually exists in security critical contexts, you get to trust system call wrappers written mostly solo by the author of Fil-C instead.
Against this background, crashing when inline assembly is determined to be doing something the author isn't sure how to deal with is pretty much par for the course -- it's a way to continue to claim that you can port over your old buggy C applications unchanged. You aren't supposed to actually use it.
Steelmanning this decision:
I would guess for the use-case of "I have a C project and I want to run it in Fil-C" the ability for this to be a warning + run-time panic is very helpful for quickly getting started. Reminds me of GHC's -fdefer-type-errors.
I agree that I wouldn't want to deploy a program where those panics are reachable*, but it's still handy for local development and/or maybe the developer knows they aren't reachable.
I haven't checked, but I'd guess there's a warning and a -Werror -style flag to opt-in to having a hard error for unsafe assembly?
* Obviously a panic is better than not. But guaranteed safeness is better than either of those.