trying to make my "fillvalues" function work...

[Keith Thompson]

As long as your operating system or implementation does not
_guarantee_ you that allocated storage is taken care of as if
you had free()d it explicitly, I'd rather explicitly free()
the storage.

Agreed, for several reasons (which you've already covered): the
program might some day become a function within a larger program, and
free() can sometimes show allocation errors that you would have
missed).

The common wisdom seems to be that memory allocated by malloc() will
*usually* be automatically deallocated by the operating system when
the program terminates (and will almost certainly be deallocated on
any modern OS), but that it's not guaranteed. I agree that it's not
guaranteed, but on the other hand, it's also not guaranteed that
calling free() will actually do any good.

More concretely:

#include <stdlib.h>
int main(void)
{
void *ptr = malloc(1000);
if (ptr == NULL) exit(EXIT_FAILURE);
#ifdef CALL_FREE
free(ptr);
#endif
exit(EXIT_SUCCESS);
}

On most systems, I'd expect the program to behave the same way whether
CALL_FREE is defined or not, i.e., the allocated memory will be
reclaimed when the program terminates. But if this program causes a
system-level memory leak without CALL_FREE, is there any reason to
assume defining CALL_FREE will plug the leak? Calling free() merely
causes the allocated space to be "made available for further
allocation", presumably within the program itself. It doesn't
necessarily return the space to the operating system *or* cause it to
be returned to the OS when the program terminates.

Are there any real-world systems where the above program actually
causes a memory leak with CALL_FREE not defined? If so, does defining
CALL_FREE actually plug the leak on all such systems?

None of this affects the principle that you should always free() all
the memory you malloc().

 

[CBFalconer]

Agreed, for several reasons (which you've already covered): the
program might some day become a function within a larger program,
and free() can sometimes show allocation errors that you would
have missed).

There is one situation where you may want to avoid the 'free on
exit' action. This is where a large number of objects have been
allocated, and the free mechanism requires O(n) time to combine
free memory blocks (where n is the number of allocations in
effect). This can result in an O(n * n) action at program exit.

The test code for hashlib has provisions for enabling and disabling
this final action, and thus provides a way of measuring your
systems performance. This fault in free, which I found in all
libraries available to me, was the impetus behind my nmalloc system
for DJGPP. nmalloc makes all operation O(1), and obviates the
problem.

Your can find the relevant code (hashlib and nmalloc) at:

<http://cbfalconer.home.att.net/download/>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Dave Thompson]

There is one situation where you may want to avoid the 'free on
exit' action. This is where a large number of objects have been
allocated, and the free mechanism requires O(n) time to combine
free memory blocks (where n is the number of allocations in
effect). This can result in an O(n * n) action at program exit.

Another is where you have built a (complex) linked structure in
virtual memory significantly larger than available physical memory, so
that walking to free it requires swapping it (all) in, while OS-level
process cleanup can just discard the pages. This is usually O(n) or
slightly more, but with a large enough k to be troublesome.

The test code for hashlib has provisions for enabling and disabling
this final action, <snip>

I like that. It is almost always easier to include the free's while
originally coding and later remove or disable them, than to omit them
and later try to find or remember all the right places to add them.

- David.Thompson1 at worldnet.att.net