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

[Havoc Pennington <rhp zirx pair com>]

On Thu, 18 Mar 1999, Ulric Eriksson wrote:
> 
> On Thu, 18 Mar 1999, Havoc Pennington wrote:
> 
> > The GMemChunk (which is what we're talking about) only stores pools of
> > equal-sized memory chunks. So you can't get unusable holes in the memory.
> > It's impossible on-face.
> 
> The same way it's impossible to get memory leaks when you by design never
> free anything? ;-)
> 
> Areas of memory that are set aside for a rainy day but not used are by
> definition unusable holes.
>

No. They are by definition *unused* holes, which is a different matter
(though still a problem, a different problem).
 
> > Look, the glib authors are smart guys. It is stupid to go on about how
> > glib may or may not have some random design flaw when you haven't even
> > read the code and figured out how it works. At least do some profiling 
> > on your own.
> 
> I have read the code. What strikes me as "stupid", no offense intended, is
> to go on about how somebody is a smart guy and doesn't make mistakes.
> 
> Unless the design has been profiled or is at least supported by some form
> of calculation, it is indeed "random".

I'm not saying they don't make mistakes. I'm saying they have most likely
already thought about these issues, and there is no point demanding that
they re-hash their thoughts just so that everyone knows they have indeed
thought about it. Especially when they have already done so a couple of
times in the past on this list.

If you have actual profiling data data or a comment on the actual code
which shows there's a problem or bug, then it's a different matter.
Especially if you have a proposed solution for said problem or bug. But an
abstract discussion of the merits of managing one's own memory is not
really relevant since there is a concrete implementation to be discussed.

Let's drop the thread until the above concrete information appears.

Havoc