gnupic: Re: [gnupic] gpasm memory leaks
Subject:
Re: [gnupic] gpasm memory leaks
From:
Robert Pearce ####@####.####
Date:
4 Jun 2007 22:33:58 +0100
Message-Id: <20070604223355.c8b87d64.rob@bdt-home.demon.co.uk>
On Mon, 04 Jun 2007 13:28:05 -0700
Scott Dattalo ####@####.#### wrote:
> David,
>
> However, in general
> for small programs that have constrained memory footprint I don't even
> bother with deallocating memory. gpasm sort of fits into that category.
> On the other hand, gpasm is really just a part of gputils which consists
> of several utilities and a library. If we anticipate the library being
> used in some other application where memory consumption is critical,
> then free'ing memory is a good idea. The pCode optimizer may be such a
> case.
In general, I _never_ leave allocated memory leaking, even for a very
small program. However, my reasoning is much more akin to Scott's: if I
ever wanted to reuse that code then having unhandled memory leaks may
prove to be a problem. Far better to design the thing right in the
first place, even if it's (a little bit) more work.
That said, for tools "like" gpasm (in that they conceptually read in
and process lots of stuff, then exit) the cleaning up often happens
just before the program terminates. After all, trying to figure out
whether an entry in the symbol table will become redundant before the
end of pass 2 is too much effort for too little gain.
And as to the "don't free it because that way avoids trying to use
already free'd heap" argument... I shall restrain from my instinctive
one word answer and merely point out that the last program "of this
sort" (i.e. part of a build environment and behaving something like a
compiler) that I inherited from a third party (actually a student)
whose approach to heap memory was less than rigourous, adopted that
approach and contained so many tough to find memory allocation errors
you wouldn't believe it. It leaked like a sieve _and_ regularly used
memory it hadn't really allocated.
I know this is an open source hacker community, but that doesn't change
the truth - discipline in software development is a Good Thing.
