Comment by pizlonator
2 days ago
Invisicaps are not exactly fat pointers.
Fat pointers show up inline in memory, which has a bunch of problems:
- sizeof(void*) changes
- either you let the bounds get corrupted by bad casts, unions, and other issues, or you impose restrictions that prevent unions from working compatibly, or you end up supporting unions by having issues with races, or you need special hardware. Invisicaps sidestep all of those issues
The "flight pointer" looks an awful lot like a fat pointer. See the diagram at "The intuition of inviscaps" in [1]. A "flight pointer" has a pointer to the beginning of the buffer, which they call the "lower bound ptr", and a pointer to someplace within the buffer, which they call the "integer ptr". The pointer to the beginning of the buffer lets the checker find the size of the buffer, which is stored preceding the buffer. The compiler has to arrange things so that the lower bound ptr is carried around wherever a "flight pointer" goes. This is supposed to be invisible to the programmer.
[1] https://fil-c.org/invisicaps
other implementations of fat pointers (that I’m aware of) have no distinction between flight and rest; they store what I call flight pointers in memory literally.
The closest technique to invisicaps is softbound, but that has issues that invisicaps resolve (better story for races, more comprehensive safety for all of the C and C++ languages, no need for large virtual memory reservations, and lock freedom)