gnupic: Re: [gnupic] gpasm memory leaks
Subject:
Re: [gnupic] gpasm memory leaks
From:
Robert Pearce ####@####.####
Date:
1 Jun 2007 18:40:35 +0100
Message-Id: <20070601184032.41d03449.rob@bdt-home.demon.co.uk>
On the subject of where to call malloc,
On Fri, 1 Jun 2007 09:21:52 -0500 David wrote:
> Anyway, I was really asking whether doing so would open up new problems, and
> whether that reorganization would be considered more trouble than it's
> worth.
I'd probably consider it more trouble than I could be bothered with ;)
But I doubt it would open any particular problems unless there are
hidden assumptions in the structure of the code. That, however, is an
application design issue, not a language one.
> So,
> would you usually recommend leaving the allocation where it is and working
> around it when there are leaks? If you want to see what I'm looking at and
> you have the source, it's all the calls to the push_symbol_table function in
> libgputils/gpsymbol.c. I don't think the code even attempts to free them.
I'd normally recommend leaving the existing design decisions unless
they're clearly broken. I'm not sure the function name
"push_symbol_table" strikes me as suggestive of being in the class of
functions like malloc, but what it does strikes me as clearly belonging
in that class. It looks like it really ought to be called
"symbol_table_new", and its companion "pop_symbol_table" would then be
"symbol_table_delete". If that ties up with their usage (which I
haven't confirmed) then the "pop" function ought to free the deleted
object. If the usage breaks catastrophically with that change, then the
design would seem to be broken.
Does that help at all?
Rob
