Do you actually want a fat-pointer specifically, or do you just want an efficient way to associate metadata with C pointers? Because (as I‘m sure you know) fat pointers have serious compatibility problems with external libraries, and also may break C programs in other ways due to lack of sound type information.
John Criswell (copied) had created an improved version of Baggy Bounds which gives a efficient and compatible solution at low memory overhead. I suggest contacting him if you’re interested.
I’m working on the Checked C project (https://www.microsoft.com/en-us/research/project/checked-c/)
to enhance it with temporal memory safety. Fundamentally we want an (super) efficient way
(ideally with less than 5% performance overhead) of associating metadata with C pointers,
and the reason we chose fat pointer is we believe this would be the most efficient way,
although at the cost of breaking the backward compatibility. I’ve done a literature survey and
found that most solutions (e.g., CETS, DANGNULL, FreeSentry, DangSan, etc) use disjoint data structures
to keep track of the point-to relations and maintaining the data structures is where all
the overhead (both performance and memory) comes from, and none of the existing solutions
are fast enough. I worked on this project last summer at Microsoft with David Tarditi, and
our conclusion is that fat pointer is the way to go if speed and memory consumption are more
critical issues than compatibility.
Actually I’ve discussed this issue with John and we have received a small grant from Microsoft Research
with the "fat-pointer” design in the proposal (John is my advisor at Rochester :-)) . John talked
about implementing the fat pointer using an llvm vector or 128-bit integer, but we would still have
the type mismatch problem because in lots of places the compiler is expecting an llvm::PointerType.
I’ll discuss this more with John.