upvote

points

by rurban10 hours ago |
comments
upvoteby mrgriffin9 hours ago|
next
[-]
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.

reply
upvoteby flotzam5 hours ago|
prev|
next
[-]
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."

reply
upvoteby pizlonator4 hours ago|
parent|
[-]
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

reply
upvoteby Jweb_Guru5 hours ago|
prev|
[-]
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.

reply
upvoteby pizlonator4 hours ago|
parent|
next
[-]
> 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

reply
upvoteby layer83 hours ago|
parent|
prev|
next
[-]
> 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?

reply
upvoteby wavemode3 hours ago|
parent|
prev|
next
[-]
This comment is astonishingly uncharitable and also mostly wrong. Do better.
reply
upvoteby achierius1 hours ago|
parent|
prev|
[-]
> 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.

reply