NULL pointer in overloaded operator delete []

Discussion in 'C++' started by Rahul, Nov 13, 2008.

  1. Rahul

    Rahul Guest

    Please read the following code

    class Test{
    public:
    void * operator new [] (size_t t)
    { return malloc(t); }

    void operator delete [] (void *p)
    { free(p); }
    };

    void main () {

    Test *p= 0;

    delete [] p;

    /* What should happen here, Should the call go inside Test::eek:perator
    delete []. Because what I learned from books is that deleting a NULL
    pointer is safe (calling ::eek:perator delete[] on a NULL pointer does
    not crash). But here it causes a crash on Sun CC because it gets
    inside Test::eek:perator delete [] whereas on VC++ and g++ it doesn't.

    Should I put a check in Test::eek:perator delete [] for "p!
    =NULL"? Is Sun CC behaving as per the C++ standard?
    */
    }


    Thanks in advance
    Rahul, Nov 13, 2008
    #1
    1. Advertising

  2. Rahul wrote:
    > Please read the following code
    >
    > class Test{
    > public:
    > void * operator new [] (size_t t)
    > { return malloc(t); }
    >
    > void operator delete [] (void *p)
    > { free(p); }
    > };
    >
    > void main () {
    >
    > Test *p= 0;
    >
    > delete [] p;
    >
    > /* What should happen here, Should the call go inside Test::eek:perator
    > delete []. Because what I learned from books is that deleting a NULL
    > pointer is safe (calling ::eek:perator delete[] on a NULL pointer does
    > not crash). But here it causes a crash on Sun CC because it gets
    > inside Test::eek:perator delete [] whereas on VC++ and g++ it doesn't.
    >
    > Should I put a check in Test::eek:perator delete [] for "p!
    > =NULL"? Is Sun CC behaving as per the C++ standard?
    > */
    > }


    Unfortunately, the language specification is (was?) not sufficiently
    clear on whether the control should go into the overloaded 'operator
    delete' when the delete-expression is invoked on the null-pointer of
    corresponding type, even though the standard does say that
    delete-expression on null-pointer is a no-op. Apparently Sun compiler
    thinks that it should be called.

    Meanwhile, I don't understand why it crashes on Sun, even if it gets
    into the above 'operator delete[]'. The standard 'free' function is also
    a no-op on a null-pointer argument. If it crashes, that would mean that
    there's a bug in Sun's 'free' implementation.

    BTW, how do you know that VC and g++ don't call it? You really checked
    it or you just assumed it because it didn't crash?

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Nov 13, 2008
    #2
    1. Advertising

  3. Rahul

    Rahul Guest

    On Nov 13, 8:13 pm, Andrey Tarasevich <>
    wrote:
    > Rahul wrote:
    > > Please read the following code

    >
    > > class Test{
    > > public:
    > >         void * operator new [] (size_t t)
    > >         {       return malloc(t);       }

    >
    > >         void operator delete [] (void *p)
    > >         {        free(p);       }
    > > };

    >
    > > void main () {

    >
    > > Test *p= 0;

    >
    > > delete [] p;

    >
    > > /* What should happen here, Should the call go inside Test::eek:perator
    > > delete []. Because what I  learned from books is that deleting a NULL
    > > pointer is safe (calling ::eek:perator delete[] on a NULL pointer does
    > > not crash). But here it causes a crash on Sun CC because it gets
    > > inside Test::eek:perator delete [] whereas on VC++ and g++ it doesn't.

    >
    > >         Should I put a check in Test::eek:perator delete [] for "p!
    > > =NULL"? Is Sun CC behaving as per the C++ standard?
    > > */
    > > }

    >
    > Unfortunately, the language specification is (was?) not sufficiently
    > clear on whether the control should go into the overloaded 'operator
    > delete' when the delete-expression is invoked on the null-pointer of
    > corresponding type, even though the standard does say that
    > delete-expression on null-pointer is a no-op. Apparently Sun compiler
    > thinks that it should be called.
    >
    > Meanwhile, I don't understand why it crashes on Sun, even if it gets
    > into the above 'operator delete[]'. The standard 'free' function is also
    > a no-op on a null-pointer argument. If it crashes, that would mean that
    > there's a bug in Sun's 'free' implementation.
    >
    > BTW, how do you know that VC and g++ don't call it? You really checked
    > it or you just assumed it because it didn't crash?
    >
    > --
    > Best regards,
    > Andrey Tarasevich- Hide quoted text -
    >
    > - Show quoted text -


    Hi,

    Sorry for my ignorance. But that is just a dummy code which I wrote
    quickly, so actually its "int main" only
    and the operator delete [] does not call free(), It manages a double
    linked list internally and de-references the pointer p before actually
    freeing the memory. Which causes a crash.

    So I wanted to know if I should put a platform specific NULL check in
    operator delete [] OR should make it general. Doing that would
    penalize other platforms un-necessarily, of-course the cost is not
    much considering the whole application. But my point is, why to
    penalize other platforms if they are behaving as per the standard (If
    at all they are ).”
    Rahul, Nov 13, 2008
    #3
  4. Rahul wrote:
    >
    > So I wanted to know if I should put a platform specific NULL check in
    > operator delete [] OR should make it general. Doing that would
    > penalize other platforms un-necessarily, of-course the cost is not
    > much considering the whole application. But my point is, why to
    > penalize other platforms if they are behaving as per the standard (If
    > at all they are ).”


    I would recommend you to pot a _general_ null-pointer check into your
    overloaded 'operator delete[]'. The reason for this is that technically
    'operator delete[]' is by itself a standalone self-sufficient
    resource-deallocation function. It can actually be called explicitly by
    the user, should the need arise. I'd say that there's a de-facto
    standard (or at least a widespread and accepted practice) to write all
    resource deallocation functions so that they permit a null argument and
    act as a no-op in that case.

    Of course, I understand perfectly well that overloaded 'operator delete'
    is not normally intended to be used as a self-sufficient function. But
    nevertheless it feels like a good idea to preserve the null->no-op
    guarantee for this function as well. (Standard library-provided versions
    do that, BTW.) The overhead of doing the null check is less than
    negligible, so I'd remove the issue of "penalizing the other platforms"
    from consideration entirely.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Nov 13, 2008
    #4
  5. Rahul

    James Kanze Guest

    On Nov 13, 2:50 pm, Victor Bazarov <> wrote:
    > Rahul wrote:
    > > Please read the following code


    > > class Test{
    > > public:
    > >         void * operator new [] (size_t t)
    > >         {       return malloc(t);       }

    >
    > >         void operator delete [] (void *p)
    > >         {        free(p);       }
    > > };


    > > void main () {


    > > Test *p= 0;


    > > delete [] p;


    > > /* What should happen here,  Should the call go inside Test::eek:perator
    > > delete []. Because what I  learned from books is that deleting a NULL
    > > pointer is safe (calling ::eek:perator delete[] on a NULL pointer does
    > > not crash). But here it causes a crash on Sun CC because it gets
    > > inside Test::eek:perator delete [] whereas on VC++ and g++ it doesn't.


    > >         Should I put a check in Test::eek:perator delete [] for "p!
    > > =NULL"? Is Sun CC behaving as per the C++ standard?


    > The behaviour of your program is undefined.  'main' must
    > return the type 'int':


    Not undefined. It's an error which requires a diagnosis.

    Of course, that is completely orthogonal to his question.

    >     int main() {


    > Seriously, though, everything should be OK because 'free' is
    > explicitly specified as a NOP if its argument is a null
    > pointer.


    > You need to investigate further why on Sun it doesn't go into
    > the overloaded operator delete[].  And even if you don't
    > overload, the deletion (using 'delete' or 'delete[]') is
    > explicitly defined as OK if the argument is a null pointer.


    It's still the responisiblity of operator delete (or delete[])
    to check; the standard doesn't guarantee that it won't be given
    a null pointer; the standard requires that it be a no-op if
    given a null pointer.

    But of course, all he's doing is calling free() with the pointer,
    and free() is guaranteed to be a no-op when given a null
    pointer, so his implementation meets the requirements.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Nov 13, 2008
    #5
  6. Rahul

    James Kanze Guest

    On Nov 13, 4:13 pm, Andrey Tarasevich <>
    wrote:
    > Rahul wrote:
    > > Please read the following code


    > > class Test{
    > > public:
    > >         void * operator new [] (size_t t)
    > >         {       return malloc(t);       }

    >
    > >         void operator delete [] (void *p)
    > >         {        free(p);       }
    > > };


    > > void main () {


    > > Test *p= 0;


    > > delete [] p;


    > > /* What should happen here, Should the call go inside Test::eek:perator
    > > delete []. Because what I  learned from books is that deleting a NULL
    > > pointer is safe (calling ::eek:perator delete[] on a NULL pointer does
    > > not crash). But here it causes a crash on Sun CC because it gets
    > > inside Test::eek:perator delete [] whereas on VC++ and g++ it doesn't.


    > >         Should I put a check in Test::eek:perator delete [] for "p!
    > > =NULL"? Is Sun CC behaving as per the C++ standard?
    > > */
    > > }


    > Unfortunately, the language specification is (was?) not
    > sufficiently clear on whether the control should go into the
    > overloaded 'operator delete' when the delete-expression is
    > invoked on the null-pointer of corresponding type, even though
    > the standard does say that delete-expression on null-pointer
    > is a no-op. Apparently Sun compiler thinks that it should be
    > called.


    Or that the implementation is allowed to call it. According to
    the latest draft, "The value of the first argument supplied to a
    deallocation function may be a null pointer value; if so, and if
    the deallocation function is one supplied in the standard
    library, the call has no effect." I'm not quite sure what the
    implications of that "is one supplied in the standard library"
    are meant to be---taken literally, since his function is not one
    provided by the standard library, the sentence wouldn't seem to
    apply. But somehow, that doesn't make sense.

    It may be worth raising the issue with the committee.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Nov 13, 2008
    #6
  7. Andrey Tarasevich, Nov 13, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mathieu Malaterre

    delete NULL, what about delete[] NULL

    Mathieu Malaterre, Aug 17, 2004, in forum: C++
    Replies:
    2
    Views:
    3,808
    Mathieu Malaterre
    Aug 17, 2004
  2. Tristan Wibberley
    Replies:
    18
    Views:
    741
    James Kanze
    Sep 25, 2007
  3. aneuryzma
    Replies:
    3
    Views:
    693
    Jim Langston
    Jun 16, 2008
  4. Alex Vinokur
    Replies:
    0
    Views:
    462
    Alex Vinokur
    Jun 14, 2012
  5. Alex Vinokur
    Replies:
    3
    Views:
    492
    Zoltan Juhasz
    Jun 15, 2012
Loading...

Share This Page