> 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?

This comment is astonishingly uncharitable and also mostly wrong. Do better.

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