[GEN][ZH] Fix undefined behavior with MemoryPoolObject::deleteInstance#870
Conversation
xezon
force-pushed
the
xezon/fix-deleteinstance
branch
from
0d29aab to
aff2d7d
Compare
Mauller
left a comment
Mauller
left a comment
There was a problem hiding this comment.
Nothing wrong with how things have been changed, just a few places where things could be cleaned up due to the change in implementation.
There was a problem hiding this comment.
Same heres as mentioned above, might be better to use mpo as the argument name. Although this one is talking about actual object class objects, but maybe the argument should be of type MemoryPoolObject*?
There was a problem hiding this comment.
I actually intentionally put Object* here, because it is meant to destroy an Object, and not some other type right?
There was a problem hiding this comment.
Yeah it makes sense, i was considering that the underlying deleteInstance expects a MemoryPoolObject so that gets hidden in a way. But i think an Object is always a MemoryPoolObject so it shouldn't be an issue.
xezon
force-pushed
the
xezon/fix-deleteinstance
branch
from
aff2d7d to
36655fd
Compare
|
Addressed most comments. See fixup! commits. |
xezon
force-pushed
the
xezon/fix-deleteinstance
branch
from
36655fd to
3a6ea79
Compare
|
Tested against VS6 golden replay. Passed that. |
2 participants
Merge with Rebase
This change fixes the undefined behaviour in
MemoryPoolObject::deleteInstanceby making it a static function. This way null pointers are no longer dereferenced when calling it. This change was mostly applied with a python script to avoid editing 1000 lines by hand.MemoryPoolObject::deleteInstancealso gets an alias functiondeleteInstancefor simplicity.The
MEMORY_POOL_DELETEINSTANCE_VISIBILITYmacro was removed because it no longer is applicable with the static function. Instead, accidental calls todeleteInstance(Object*)are prevented with a deleted function.