RE: Eliminating GCC 3.3 warning

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

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?

-----Original Message-----
From: Bob Friesenhahn [mailto:[email protected]] 
Sent: Friday, May 16, 2003 1:11 PM
To: GraphicsMagick Core
Cc: Bill Radcliffe
Subject: Re: [GM-core] Eliminating GCC 3.3 warning

Here is a set of macro definitions which seem ok to me. They eliminate
explicit casts (presumably decreasing the opportunity for a bad cast)
and eliminate the new GCC warning. The macros would only be used by
the implementation so there would be no modification to the API.  It
may be that the MagickAllocateMemory macro is a bit "over the top"
since it passes the return pointer type as a macro parameter.  I am
including some sample usages.

#if defined(MAGICK_IMPLEMENTATION)

#define MagickAllocateMemory(type,size) ((type) AcquireMemory(size))

#define MagickFreeMemory(memory) \
{ \
    assert(memory != 0); \
    void *_magick_mp=memory; \
    if (_magick_mp != 0) LiberateMemory(&_magick_mp); \
    memory=0; \
}

#define MagickReallocMemory(memory,size) \
{ \
    assert(memory != 0); \
    void *_magick_mp=memory; \
    ReacquireMemory(&_magick_mp, size); \
    memory=_magick_mp; \
}

#endif /* defined(MAGICK_IMPLEMENTATION) */

/* allocate some memory */
destination=MagickAllocateMemory(char *,strlen(source)+1);

/* free some memory */
MagickFreeMemory(decode);

/* reallocate some memory */
MagickReallocMemory(*destination,strlen(source)+MaxTextExtent);

======================================
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