John Andrew Fingerhut (jaf3@ritz.cec.wustl.edu) wrote:
: I have a library that overloads operator delete.  Their function does
: not check to see if the pointer is 0 before cleaning up the freestore.
: According to the ARM...invoking delete on 0 is "guaranteed to be harmless."
: Yet, under Sun C++ 4.0, this program blows up when delete is called on
: 0.  Is this guarantee only true for the delete that is not overloaded,
: or should operator delete never be called with a 0 pointer?

: Stephen Gevers
: sg3235@shelob.sbc.com


In the case of the Borland compiler it checks for non-NULL before calling
delete.  In effect, 'delete foo' becomes 'if (foo) ::operator delete(foo);'.
*However*, it is important that the delete routine regardless of the compiler
used check for NULL as ::operator delete can be called directly and the ARM
states that this should be harmless.

Steve Simpson                   | "The right of the people to keep and bear
ssimpson@world.std.com          | arms shall not be infringed."
Software Engineering Consultant | Second Ammendment to the U.S. Constitution

In article <35spfo$rua@ritz.cec.wustl.edu> sg3235@shelob.sbc.com writes:
>I have a library that overloads operator delete.  Their function does
>not check to see if the pointer is 0 before cleaning up the freestore.
>According to the ARM...invoking delete on 0 is "guaranteed to be harmless."
>Yet, under Sun C++ 4.0, this program blows up when delete is called on
>0.  Is this guarantee only true for the delete that is not overloaded,
>or should operator delete never be called with a 0 pointer?

It's a good question.

My understanding is that whenever the user defines his or her own file-
scope new or delete operators, these user-supplied implementations will
be effectively required to satisfy the terms of a kind of `contract'
between the implementation as a whole, and the user's definitions of
these operators, and that if the user's definition(s) FAIL to live up
to the terms of the contract (which will, I believe be spelled out in
the final C++ standard) then the user's entire program will then be
said to exibit `undefined behavior'.

(I'm sure someone on the committee will correct me if I am wrong about
any of this.)

Anyway, if that is all correct, then presumably the ability of a user-
supplied version of the file-scope delete operator to gracefully handle
an actual argument of zero will be a part of the contractual requirements
which the *user* must fulfill (in order to avoud the dreaded `undefined
behavior').

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article rua@ritz.cec.wustl.edu, jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) writes:
>I have a library that overloads operator delete.  Their function does
>not check to see if the pointer is 0 before cleaning up the freestore.
>According to the ARM...invoking delete on 0 is "guaranteed to be harmless."
>Yet, under Sun C++ 4.0, this program blows up when delete is called on
>0.  Is this guarantee only true for the delete that is not overloaded,
>or should operator delete never be called with a 0 pointer?

The language rule is that
 delete p;
is harmless if p is a null pointer. This expression invokes the appropriate
version of operator delete(). Therefore, Any user-supplied operator delete()
should ensure that calling it with a null pointer is harmless, or programs
may fail, as is apparently the case with yours. You have a legitimate
complaint for the author of the overloaded delete function.

---
Steve Clamage, stephen.clamage@eng.sun.com

I have a library that overloads operator delete.  Their function does
not check to see if the pointer is 0 before cleaning up the freestore.
According to the ARM...invoking delete on 0 is "guaranteed to be harmless."
Yet, under Sun C++ 4.0, this program blows up when delete is called on
0.  Is this guarantee only true for the delete that is not overloaded,
or should operator delete never be called with a 0 pointer?

Stephen Gevers
sg3235@shelob.sbc.com