Re: gcc support for memory debuggers (operator delete) ?

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  1, 2003, Felvegi Peter Andras <petschy@lucifer.kgt.bme.hu> wrote:

> - does anybody know a workaround to the above problem ? ie a method that:
>   * ensures that exiting code need not be modified (apart from including
>   the memory debugger header)

Not really.

> - if the answer is 'no' to the above question, do you think it would
>   make sense to put support into gcc for the following features:

This would be a deviation from the C++ Standard.  As much as the
asymmetry between new and delete sucks, it's part of the language, and
any extension we introduce to this effect will still require changes
in programs that don't use this extension, so it won't solve the
problem.  In C++, operator delete (void *, other args) is called
*only* when the constructor implicitly called by a new (other args)
expression throws, to delete the incompletely-constructed object.

>   * force the call of operator delete even if the pointer is NULL

Doesn't sound like something you would want to enable by default.

>   the first would be sufficient for the comma expression case to work
>   properly

except, maybe, for operator precedence issues.  Remember that delete
may be part of a more complex expression, and then using the comma
operator may get things wrong.

Consider trying mudflap, that is integrated with GCC (tree-ssa
branch), so it doesn't have to resort to preprocessing hacks to get
the information it needs.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer