Re: Solutions to gmem.c ENABLE_MEM_CHECK crashes

[Kenneth Albanowski <kjahds kjahds com>]

On Mon, 19 Oct 1998, Phil Schwan wrote:

> On Oct 19, Martin Pool wrote:
> > 1. Keep gmem.c as it is, and report attempts to free() gmem blocks as
> >    bugs to the program authors, with patches.  Put in big flashing
> >    warnings not to do this into the FAQ and documentation.
> 
> Isn't this already the case...?  I see no problem with requiring the
> use of g_free, g_realloc, etc, as common sense dictates (to me
> anyways) that this should already be the case.  If you're going to use
> a tool to allocate, you should certainly use the same tool to free
> (for another example, see libPropList).

More generally: any library (such as ORBit or Gtk) that needs to free
objects that originally belonged to some other chunk of code should invoke
a user-supplied callback to free the object.  Calling free() is no more
useful with a g_malloc()'d object then it is with a compile-time global. 

> -Phil

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)