ojhunt wrote: I'm not sure what semantics are being applied here. The comments seem to imply an ability to apply abstract machine semantics to memory passed to a delete operator _within_ the implementation of operator delete, which I don't believe is sound for any implementation of operator delete (ignoring destroying delete in which the pointer passed in is definitionally still alive).
The implementation of delete operators, at least the global variants, is definitionally outside of the abstract machine. If we apply a model of "manipulating the content of memory passed to operator delete" then we end up saying that essentially all existing allocators are incorrect: free lists are invalid as you're reading/writing dead memory, hardened allocators are invalid for similar reasons, allocators that scrub/zero on free are invalid. Alternatively we would say that all allocators must call `new (ptr) <Internal type>(..)` to re-start the lifetime of the memory as the internal allocator object, and then run that destructor prior to returning a pointer from operator new. Although this would mean that after calling `operator delete(ptr)` ptr would now be live, e.g. a hypothetical operator delete that did `new (ptr) char[allocation size]` would mean `ptr` would now be usable as a live char buffer, which undermines the "ptr is dead after deletion" claim. https://github.com/llvm/llvm-project/pull/183347 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
