alt Hacker News> asserting that racing code will panic safely on tear, which is factually incorrect
Try it. That’s what happens.
> through its loaded capabilities, which is factually correct but a non sequitur for the subject at hand.
It’s literally the safety property that Fil-C guarantees.
Safety properties provided by languages aren’t about preventing every bad thing that users can imagine. Just because the language does something different than what you expect - even if it allows you to write a program with a security bug - doesn’t mean that the language in question isn’t memory safe.
> You're shredding your credibility for nothing. You can instead just acknowledge Fil-C provides memory safety only for code correctly synchronized under the C memory model.
Fil-C provides memory safety even for incorrectly synchronized code. That safety guarantee is easy to understand and easy to verify: you only get to access the memory of the capability you actually loaded. You’re trying to evade this definition by getting hung up on what the pointer’s intval was, and your PoC uses a pointer comparison to illustrate that. You’re right that the intval is untrusted under Fil-C rules.
I’m not going to downplay the guarantees of my technology just to appease you. Whether or not you find me credible is less important to me than being honest about what Fil-C guarantees.
In https://news.ycombinator.com/item?id=46270657, you write
> If you set the index to `((alice - bob) / sizeof(...))` then that will fail under Fil-C’s rules (unless you get lucky with the torn capability and the capability refers to Alice).
In the comment above, you write, referring to a fault on access through a torn capability
> Try it. That’s what happens.
Your position would be clearer if you could resolve this contradiction, which you've made a few times now already.
> You’re right that the intval is untrusted under Fil-C rules.
Can Fil-C compile C? In C, the "intval" of a pointer is the pointer and is trusted with respect to predicting the result of program execution.
You can't on one hand argue that 1) it's the capability, not your "intval", that is the real pointer with respect to execution flow and simultaneously 2) claim to compile C, in which the "intval" has semantic meaning. C programs don't deal in your capabilities. There's not even a clean way to access them. C programs deal with pointers, and under Fil-C, under data races, a pointer can access the wrong object.
But we've gone back and forth a few times on this already. If you want to try to redefine terms by spamming the internet with claims that make sense only under your private definitions, go ahead.