[stensal]

Yes, you have stated it correctly. The size and liveness information are from allocations (either stack or heap). ASAN and Valgrind do not associate these information with pointers, but add redzones (extra paddings with special bit patterns) before and after each legit memory block. It only triggers error reporting if a pointer happens to point to one of the redzones. However, redzones always have limited sizes. They cannot cover the ranges of out-of-bound pointers.

It's dynamic typing.

[cryptonector]

Are pointers in this environment bigger than usual? Or do they point at a descriptor that then points at (or contains) the real object?

How does type punning work? Does you compiler scribble the types a pointer has been cast to in the object descriptor?

[stensal]

No, the pointer always has the native pointer size. I think the type in my use of "dynamic type system" confused you. The type has a very narrow meaning, it has only two values. It is either POINTER or NON_POINTER. A POINTER type is like a tuple of size and liveness. It does not track the static types like integer, float, or struct, etc. Hope this clarify it. Perhaps, I should call it 'dynamic pointer tracking system'. Does it sound more clear?

[cryptonector]

That helps.

In my mind I was picturing a double-wide pointer that (assuming 48-bit address spaces) carries 20 bits of type information, a pointer to an allocation descriptor, a pointer to / into the object, and 16-bit CRC of the allocation descriptor. The allocation descriptor itself would have a base address and size, a generation number, and maybe some bits for something else (what? perhaps another CRC?).

However, this would change the ABI...

And yes, I thought you were encoding the C type of the object pointed to in the pointer, which is why I was thinking wide pointers.

Thanks for the clarification!

[stensal]

I changed it to "dynamic pointer typing". Thanks for your questions.