[ptx]

I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption?

If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption?

If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.

[loeg]

It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization.

It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety.

You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.

[uryga]

i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results

(i'm not convinced that's a useful thing myself)

[littlestymaar]

> and given that random garbage could result in pretty much arbitrary "undefined behavior"

Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.

[uryga]

i put it in quotes because i meant "arbitrarily weird side-effects", but you're right that i should have used a different term