Re: glib compat w/dmalloc

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi everyone,

> My personal preference would be to completely remove DMALLOC support
> from GLib. I don't think people use it much, and also feel that if you
> want debugging malloc support, you should actually replace the libc's
> malloc/free (using libc functionality as provided with GNU libc, with
> a LD_PRELOAD, or with a library simply linked in before libc.)

You're probably right. Nobody has noticed it before now and the nonworking
dmalloc is out for almost a year now.

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

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |