gnupic: Re: [gnupic] gpasm memory leaks
Subject:
Re: [gnupic] gpasm memory leaks
From:
"David Barnett" ####@####.####
Date:
1 Jun 2007 19:29:57 +0100
Message-Id: <018f01c7a47a$31cef2c0$0301a8c0@barnett2>
----- Original Message -----
From: "Robert Pearce" ####@####.####
To: ####@####.####
Sent: Friday, June 01, 2007 12:40 PM
Subject: Re: [gnupic] gpasm memory leaks
> On the subject of where to call malloc,
> On Fri, 1 Jun 2007 09:21:52 -0500 David wrote:
<snip>
> 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.
The way the rest of the code uses pop_symbol_table, it seems like it's
supposed to somehow free the block of memory, but it doesn't. I say it
seems like it's "supposed to" because of lines like this:
/* destory the table */
file_table = pop_symbol_table(file_table);
Moving the free() into pop_symbol_table() would be the alternative to what I
was working on. As it is, just adding free() into the right place in
pop_symbol_table() seems to make the problem worse somehow.
Speaking of the naming scheme, I thought of an oddity in the behavior I
changed to. Whereas before it created a new empty symbol table and pushed
it onto the stack, now it takes an existing symbol table, empties it, and
pushes it onto the stack. It might be better to have create and/or
initialize functions and have push just push.
David Barnett
