Question

I ran into my first compiler that changes the lvalue passed to ::delete, but doesn’t zero out the lvalue. That is the following is true:

 Foo * p = new Foo();
 Foo * q = p;
 assert(p != 0);
 assert(p == q);
 ::delete p;
 assert(p != q);
 assert(p != 0);

Note that p is not zero after the delete operation, and it has changed from it’s old value. A coworker told me that this is not unusual in his experience having worked with some mainframe C++ compilers that would change p to 0xFFFFFFFF, as well as other compilers that would change p to 0.

Where in the C++ Standard does it say that a compiler is allowed to do this?

Searching through StackOverflow, I found this question: Why doesn’t delete set the pointer to NULL? which had an answer that referred to Bjarne Stroustrup’s response that includes the statement:

C++ explicitly allows an implementation of delete to zero out an lvalue operand, and I had hoped that implementations would do that, but that idea doesn’t seem to have become popular with implementers.

I’ve read and re-read section 5.3.5 and 12.5 of the final committee draft C++0x standard, but I’m not seeing the “explicit” part. Am I just looking in the wrong sections of the standard? Or is there a chain of logic that is in the sections but I’m just not connecting together properly.

I don’t have my copy of the Annotated C++ Reference Manual anymore. Was it in the ARM that a compiler could do this?

[Edit: Correcting the section reference from 3.5.3 to 5.3.5. I’m also adding an interesting paradox as a counterpoint to Henk’s assertion that p is undefined after delete.]

There is an interesting paradox if p is initialized to null.

 Foo * p = 0;
 Foo * q = p;
 assert(p == 0);
 assert(p == q);
 ::delete p;
 assert(p == q);
 assert(p == 0);

In this case though, the behavior is well documented. When delete gets a null pointer, it is suppose to do nothing, so p remains unchanged.

Answer 1

It might not be so explicit. In 5.3.5/7 it says that the delete expression will call a deallocator function. Then in 3.7.3.2/4 it says that using a pointer that has been deallocated is undefined. Since the value of the pointer cannot be used after the deallocation, then whether the pointer keeps the value or the value is changed by the implementation does not make a difference.

5.3.5/7

The delete-expression will call a deallocation function (3.7.3.2).

3.7.3.2/4

If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, render- ing invalid all pointers referring to any part of the deallocated storage. The effect of using an invalid pointer value (including passing it to a deallocation function) is undefined.

The references are from the current standard. In the upcoming standard 5.3.5/7 has been reworded:

C++0x FD 5.3.5/7

If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will call a deallocation function (3.7.4.2). Otherwise, it is unspecified whether the deallocation function will be called. [ Note: The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. — end note ]