Hacker News Reader

Comment by quotemstr | Hacker News Reader

> Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly

Fil-C as currently implemented does not guarantee panics on unsafe accesses due to races. You dodge the problem by using a private definition of safety under data race that permits program executions nobody would expect.

View on HN

I define memory safety in terms of capabilities, which is a mainstream definition.

The worst that can happen in a race is that you read or write an object that would have been accessible even in the absence of races.

The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C

I’m having a hard time understanding how these two things can be true at once. Just because the capability exists that somewhere in my program a valid pointer to a piece of memory might exist (what I understand accessible to mean), doesn’t mean that a particular write to that memory location under a data race that tears a pointer is valid. The data race may make a pointer that would never algorithmically appear in the program in the absence of races, and thus make writes that invalidate invariants that should have been preserved. It seems to me this still provides a way to corrupt memory in a difficult to debug way just like C. Am I missing something?

I've spent some more time over the last day looking at Fil-C more closely, and come to the conclusion that this:

> The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C

is just blatantly false. It's almost as easy to corrupt memory in Fil-C as it is in C. Type confusion is still allowed. You can still do out of bounds buffer reads/writes as long as they fall within an allocation, so any intra-object stuff, as you might get in common packet or binary file parsing, is still about as unsafe as it was before.

Reply on news.ycombinator.com