Re: glib compat w/dmalloc

[Tim Janik <timj gtk org>]

On Tue, 29 Feb 2000, Sebastian Wilhelmi wrote:

> > But failing that, I think that g_free() must always be a function, so
> > you simply want to remove the:
> > 
> >   #define g_free(mem)        FREE (mem)
> > 
> > in the DMALLOC case and replace simply always have a g_free() function
> > as in the non-DMALLOC case. Making every piece of software that
> > uses g_free for a GDestroyNotify, etc, broken, is not an option
> > in my opinion.
> 
> Yes, thats why I added g_free_func, which could be used. It would be a matter
> of 1/2 an hour to replace that in GTK+. If your not doing it, you might end up
> freeing memory with g_free, that you allocated with malloc which will fail for
> ENABLE_MEM_PROFILE. But as I now notice my version will of course fail for the
> same reason. So I agree, lets get rid of that.
> Should I do it or will you and should it happen for HEAD or also for glib-1-2?

i'd rather leave stable glib the way it currently defines things (i had glib +
dmalloc with the current defines working about a year ago) and for 1.3, i'll
clean up the allocation prototypes anyways when implementing g_try_malloc()
and friends.

> 
> Bye,
> Sebastian

---
ciaoTJ