RE: Eliminating GCC 3.3 warning

On Fri, 16 May 2003, Bill Radcliffe wrote:

> Is there any reason to call our internal memory functions instead of just
> calling the normal C runtime functions?

It is certainly true that macro-based wrappers can do what the
functions do and will avoid masking where the calls are made from.

One effect from not invoking memory allocators/deallocators via the
Magick functions is that in DLL environments I believe deallocations
must be from the same DLL that the memory is allocated from.  Using
Magick DLL functions assures that.  Using macros does not assure it so
there could be new bugs.  If macros are only used in the
implementation then it should be safe.  There may be some risks if
memory is passed from the Magick DLL to a DLL module (or vice versa)
and one DLL deallocates memory allocated by the other DLL.

This DLL issue bit me in Magick++ once since I had an inline function
allocating memory.  This caused the DLL which did the allocation to be
whichever DLL expanded the function. Bad.

> The current setup makes it difficult to find memory leaks. Most C runtime
> libraries have extensive diagnostics built in now and will tell you the
> function that called them, etc. With our current setup this info always
> shows that our internal API function is the caller and you have to get in
> and set breakpoints and stack back traces to find out who the real caller
> was. Does that description make sense?

Agreed.  It is easy enough to adapt the macros to use the normal free,
malloc, and realloc functions.  We would just need to take care when
using DLLs.

Bob
======================================
Bob Friesenhahn
[email protected]
http://www.simplesystems.org/users/bfriesen



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge