RE: Eliminating GCC 3.3 warning

I had this discussion about debugging with Cristy a ways back and he seemed
to think the solution was to convert the API functions into macros. Maybe we
can kill two birds with one stone.

-----Original Message-----
From: Hugh Brackett [mailto:[email protected]] 
Sent: Friday, May 16, 2003 1:37 PM
To: [email protected]; 'Bob Friesenhahn'
Subject: RE: [GM-core] Eliminating GCC 3.3 warning

I dealt with something like this (it was actually heap management) by using
macros.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
Bill Radcliffe
Sent: Friday, May 16, 2003 4:25 PM
To: 'Bob Friesenhahn'; 'GraphicsMagick Core'
Subject: RE: [GM-core] 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

_______________________________________________
Graphicsmagick-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core



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

_______________________________________________
Graphicsmagick-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core


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