Comment by rurban
10 hours ago
> 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.
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.
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."
Yeah
Also, like, this is the initial implementation so I kept it consistent with the rest of the error checking
If someone wants a compile time diagnostic they can submit a patch
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.
> You have to understand that Fil-C primarily exists as a marketing stunt.
What a bitter way to analyze a technology.
> under some circumstances Fil-C considers it legal to read a value from a totally different, possibly-inaccessible pointer when dereferencing an unrelated pointer
Fil-C does not consider such a thing to be legal.
You can only access capabilities that you legitimately loaded from the heap, from other capabilities you legitimately loaded, and so on. So, if you access a pointer, it's because you had access to the capability.
> You aren't supposed to actually use it.
Wat
> translating C's semantics into those of a related language with arbitrary but technically defined behavior instead of having UB
There is no “instead” here. A C implementation defining behavior for certain UB still falls under what a C implementation is allowed to do for UB.
I don’t know if Fil-C is a fully conforming C implementation, but it could well be. In what way is it nonconforming that would warrant describing it as implementing “a related language” and not C?
> 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)
Those two claims don't contradict eachother. Many, many people use C code not because their application needs to be blazing fast, but simply because the programs are already written in C. Rewriting a program from C into another language is likely to introduce a lot of bugs, even if the rewrite does manage to achieve 'full memory safety' (which most don't, instead liberally utilizing unsafe blocks or the equivalent). So what are such users to do, simply accept that there are going to be bugs? Fil-C seems to address a reasonable need.
This comment is astonishingly uncharitable and also mostly wrong. Do better.