Re: [gtk-list] Re: how can I trust glib when it has so many memleaks?

[Havoc Pennington <rhp zirx pair com>]

On Wed, 17 Mar 1999, Joe Pfeiffer wrote:
> Ionutz has a really good point here -- finding memory leaks is hard
> enough without having libraries that hide them.  Hmmm...  I haven't

I agree, but it appears to be a tradeoff and runtime speed is probably
more important. Maybe someone has a suggestion for getting the best of
both worlds, but none so far and this thread has been rehashed several
times that I remember.

> looked at glib's implementation, but if it has a memory
> allocation/deallocation package built into it (which I'd sort of
> expect), it ought to be reasonably straightforward to do something
> like either compile this with its current implementation or as a
> wrapper around malloc/free...

It doesn't look to me like that would work but I'm not an expert. You
might look at gslist.c for an example.

You could probably free all the memory en masse at program exit but there
was some reason I don't remember why that isn't being done. 

Havoc