[torginus]

Sorry to intrude on the discussion, but I have a hard time grasping how to produce the behavior mentioned by quotemstr. From what I understand the following program would do it:

    int arr1[] = {1, 2, 3, 4, 5};
    int arr2[] = {10, 20, 30, 40, 50};
    int *p1 = &arr1[1];  
    int *p2 = &arr2[2];  
    int *p = choose_between(p1,p2);

    //then sometime later, a function gets passed p
    // and this snippet runs
    if (p == p2) {
     //p gets torn by another thread
     return p; // this allows an illegal index/pointer combo, possibly returning p1[1]
    }

Is this program demonstrating the issue? Does this execute under Fil-C's rules without a memory fault? If not, could you provide some pseudocode that causes the described behavior?

[pizlonator]

No, this program doesn’t demonstrate the issue.

You can’t access out of bounds of whatever capability you loaded.

[quotemstr]

Fil-C lets programs access objects through the wrong pointer under data race. All over the Internet, you've responded to the tearing critique (and I'm not the only one making it) by alternatively 1) asserting that racing code will panic safely on tear, which is factually incorrect, and 2) asserting that a program can access memory only through its loaded capabilities, which is factually correct but a non sequitur for the subject at hand.

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. That's still plenty useful and nobody will think less of you for it. They'll think more, honestly.

[pizlonator]

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

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

[judofyr]

Can you show an actual minimal C program which has this problem? I’m trying to follow along here, but it’s very hard for me to understand the exact scenario you’re talking about.

[naasking]

I think at this point it's reasonable to conclude that quotemstr does not have a legitimate concern until a program demonstrating the issue can be presented.