Re: fixing memory leaks

Leonard den Ottolander wrote:
Hi Roland,

On Mon, 2004-08-16 at 12:28, Roland Illig wrote:

I'm currently trying to find and fix some memory leaks. That's rather difficult because there are many function taking a "char *" argument when a "const char *" would have sufficed. Additionally, it is not always clear where the memory should be freed.

declaration example:
/*new*/ char *g_strdup(/*in*/ const char *);

function call example:
char *s = /*new*/ g_strdup("foo");

Although I appreciate the effort towards code cleanup I am not sure if
it's a good idea to commit such comments to CVS. Partially because the
code might look very cluttered (maybe I am overestimating this), and
more importantly the fact that it might heavily interfere with existing
but uncommitted patches.

How much of the freeing and mallocing is done spanning multiple source
files? This kind of auditing could be done using local copies with the
comments added. Just keep a list of what has been audited.

If you want to do this in CVS maybe it's a good idea to wait until
bugzilla has been cleaned up a bit more before introducing such comments
into the code. By the way, do you want to add those temporarily or

They should be only temporary. As I wrote in the second part of my mail, after having documented the whole source, the most common usages should have no extra comments. In most times, a const char * means the same as a possible /*in*/ char *, and so the /*in*/ can be replaced by the language keyword const.

The other case is passing a char **. I currently do not know what is more frequent: an /*inout*/ parameter or a simple /*out*/ parameter. I guess it's the /*out*/ parameter, so we could agree that a missing comment means "can be uninitialized and will receive a value".

Perhaps we can also replace the /*free*/ comment by function names that contain the word "free". Same goes for the /*new*/ comment.

So the only comment that would appear after these substitutions would be either /*out*/ or /*inout*/. And that's not too much, I think.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]