Comment by quotemstr

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. Yes or no: does an access through a pointer with an arbitrary offset under a data race that results in that pointer's capability tearing always fault?

> You’re right that the intval is untrusted under Fil-C rules.

Can Fil-C compile C?

You can't argue, simultaneously,

1) it's the capability, not your "intval", that is the real pointer with respect to execution flow and simultaneously, and

2) that Fil-C compiles normal C in which the "intval" has semantic meaning.

Your argument is that Fil-C is correct with respect to capabilities even if pointers are transiently incorrect under data races. The trouble is that Fil-C programs can't observe these capabilities and can observe pointers, and so make control flow decisions based on these transient incorrect (you call them "untrusted") inputs.