gnupic: Re: [gnupic] gpasm memory leaks
Subject:
Re: [gnupic] gpasm memory leaks
From:
"David Barnett" ####@####.####
Date:
1 Jun 2007 15:26:34 +0100
Message-Id: <014601c7a458$33640a20$0301a8c0@barnett2>
----- Original Message -----
From: "Robert Pearce" ####@####.####
To: ####@####.####
Sent: Friday, June 01, 2007 2:17 AM
Subject: Re: [gnupic] gpasm memory leaks
> On Thu, 31 May 2007 17:32:02 -0500 David wrote:
>> BTW, for those
>> experienced with fixing memory leaks in C, is the technique of passing a
>> reference/pointer down instead of returning one up a common fix?
>
> It's not really a fix, it just allows a little more flexibility for the
> caller. Actually, a lot of the standard C library functions do it the
> other way - for example, strdup calls malloc internally and expects the
> programmer to call free on the returned string. So it would probably be
> fair to answer "no" to your question.
Sorry, I didn't mean that as the whole fix. What I meant was in most
languages you try to allocate and deallocate on the same stack level,
because it can be much harder to keep them paired otherwise. That also
allows you to statically allocate some variables you couldn't otherwise. I
guess it's most important in C++ where the logic can be spread around much
more. From that angle I consider strdup and other obvious allocation
functions in the same group as malloc.
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 thought it worth asking because I haven't spent enough time on C
projects that I know all the tricks and conventions, and I didn't want to
set to work on changes that would end up being useless or harmful. 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.
> As to your CVS question, my version of SVN rejects "svn diff -u".
So it does... I didn't really have an SVN checkout handy to try it on.
> I believe the CVS equivalent of "svn diff -x -u" is "cvs diff -u".
Yeah, looks like it is. I thought I remembered some complication to it, but
now I think about it I think it's reverting changes that's a pain. I always
have to delete the file and update it again...can't find any revert, and
'unedit' doesn't seem to do exactly the same thing. Well, sorry for the
bother, anyway. I try to get my facts straight, but sometimes there really
are stupid questions =). I know I've had a low signal-to-noise here so far.
David Barnett
