Interestingly, SillyMUD and its descendant Phoenix at one point had similar memory checks that occurred at runtime, as well as shared memory with reference counting and a paging virtual memory system.

Unfortunately, even with that and it having been run with purify (a commercial predecessor to valgrind), i was still able to find some severe memory issues that didn’t manifest by compiling with address and memory sanitization about 25 years later.

I didn't know SillyMUD. But I did read the paper about an interpretation based memory checking tool many years ago. Unfortunately, I forgot the name. I believe the interpretation based memory checking tool assigns each pointer a type. So the idea is not new.

ASAN is great because of its compatibility with existing libraries, as you have pointed out, is available in both gcc/clang. Valgrind is in the same league. Both are fantastic tools even though they might miss some errors.

OK, Thanks. Now, how does the run-time determine the type and size of an object for which the application has a pointer? The type, presumably, from static typing, but then you have to be careful with type punning. The size, presumably, from the allocation. This doesn't sound that different from ASAN and valgrind. What is different?

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.

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?

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?

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!

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