commented:
Saw the presentation on this at Software Should Work conf last week.
It is neat! The capabilities are stored in memory adjacent to the
pointers or structures they describe. So it seems like an attacker
could modify the capabilities and thus modify what memory the
capabilities allow them to access. But attackers are prevented from
doing that because the capabilities ensure that would be detected as
an out-of-bounds memory access and thus cause a crash. A nice
recursive property!

  commented:

Software Should Work conf

TIL — thank you! Looks like recordings will be uploaded to their
YouTube channel.

  commented:

InvisiCaps allow for 64-bit pointers on 64-bit systems

I was confused how this would works, but this is referring to the size
as observed by C (e.g. sizeof). Pointers still need 128 bits of memory
(plus some variable additional overhead).
Lovely work. There's a lot of C code around that's not going to be
rewritten in a memory-safe language, and some of that doesn't need the
level of performance that C offers. And while Fil-C doesn't prevent
bugs¹, crashing is often better than data corruption.
What I'm curious about is how Fil-C deals with subobjects? The page
defines memory safety in terms of objects, but if an object a is part
of a object b, how does Fil-C know/decide which of them a pointer to a
is allowed to access?
I'll also note that as far as I understand, because the pointer's
value as seen by C and its capability don't have to match up, C code
that checks a pointer's value to confirm it points to a certain object
could still write out of bounds of that object.
Edit:
¹ actually, it does prevent bugs, namely use after frees thanks to its
gc

  commented:
Semi off-topic: I love the reading experience of the Fil-C docs.
Similar to Gleam release notes, I find myself reading them even though
I have no immediate plans of using it.
I'm also a sucker for unicode text diagrams. :)
.