gcc support for memory debuggers (operator delete) ?

[Felvegi Peter Andras <petschy at lucifer dot kgt dot bme dot hu>]

hello,

 i have run into a problem writing my memory debugger for c/c++.
searched the archives, but unfortunately found no relevant discussions.
 my implementation (and others i've checked, too) do the following:

declare/define an alternative operator new that takes __FILE__ and
__LINE__ as extra arguments, and define a macro that expands 'new' to
'new(__FILE__, __LINE__)'. this works fine.

the problem occurs, when i want to do similarly with delete. though i
can define alternative delete operators, i can not call them simply,
because it will give parse error, ie 'delete(__FILE__, __LINE__) ptr;'
is invalid. i miss the simmetry here with 'new'. anyone knows the reason
why this construct is illegal?

if one types 'operator delete(ptr, __FILE__, __LINE__);' then it
compiles ok, but this form is not suitable for macro expansion. one
could write a DELETE(x) macro of course, but this would require changing
existing code at awfully many places, so this is not the way i wish to
go.

one workaround is to use a comma expression like:
#define delete	push_info(__FILE__, __LINE__), delete
where push_info() will push the file/line info to a private stack, then
the operator delete can pop off and use it. a stack is required, because
the destructors can be nested.

this works fine, except one case: deleting a NULL class pointer will
result in pushing the info but not invoking the destructor. this is all
right, since the dtor couldn't do anything with a NULL this ptr, but
because of that, operator delete won't be called either, and the
info won't be popped off. this will overflow our stack when
deleting a lot of NULL pointers. because the way we defined the macro,
there is no way deciding if the pointer is NULL before the push call.
one could do it explicitly, but this is tedious, and redundant: the
generated code from delete will check for it anyhow.

if the class/struct does not have a destructor, the above problem not
rises, delete will be called with a NULL pointer.

 my questions are:

- 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)
  * operator delete gets the needed information
  * works also if deleting NULL pointers

- 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:
  * force the call of operator delete even if the pointer is NULL
  * enable a syntax for operator delete that is symmetric with operator
    new, ie 'delete(...) ptr;' and 'delete(...) [] ptr;'
  the first would be sufficient for the comma expression case to work
  properly, the second would make things look nice. imho.
  these could be enabled with -f... options probaly.

things get a bit messy if classes define their own operators, but this
can be handled: for foreign classes, one should disable the debugger
macros when doing new/delete. for own classes one may do the same, or
implement the proper debug operators.

attached a little source to demonstrate the above concepts. compiled
under gcc 2.95.3. tried with 3.3, too, but got linker complaints (ld is
probably a bit old, as my system as a whole). since i haven't
encountered anything related in the change logs, i suppose that gcc 3.3
behaves the same way in this matter. please confirm this if possible.


						thanks, p

Attachment: opdel.cpp
Description: Text document