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

[Havoc Pennington <rhp zirx pair com>]

On Thu, 18 Mar 1999, Ionutz Borcoman wrote:
> > 
> > They can tell you better than me, but my guess is nice design, code
> > review, and observation of running programs. The same way you find any
> > other bug. No big secret techniques or anything. :-)
> 
> Wrong answer :-) The answer should be: runing something that checks the
> memory allocations/dealocations. It's like trying to debug a program by
> putting printf() instead of using gdb. Memory leaks are not seen soo
> easy by running programs.
>

To go off on a tangent, I disagree. It is better to write nice, readable
code which you've planned in advance so that you know where memory is
going to come from and where it is going to go. You won't get it perfect,
and ccmalloc and similar tools are nice to clean up the last few mistakes.
But relying on it as your primary debugging method is a poor idea IMHO.

If you are really concerned, use the STL or a garbage collector. Either of
those will almost guarantee no memory is leaked.

(Told you it was a tangent. :-)
 
> Let's say I trust the glib guys (do they have anything to say, or is
> this uninteresting for them ?) and glib has no memory leaks. How can I
> see that my program doesn't have memleaks. If your programs tries to go

If I knew how to guarantee a program was bug-free I'd be rich and famous.

If you want to get as close as possible given existing knowledge, I'd try
Haskell or something. ;-)

Seriously, I don't know how to fix glib here.

Havoc