Re: Linked List & Dynamic Memory Allocation

"one-trick-pony" <worldofpain.aamir@xxxxxxxxx> wrote in message news:1188393239.299777.238780@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I think my book has an error. Code is allocating memory with malloc
and I don't see a free call to match it.

void enterdata()
{
struct address *info;

for( ; ; )
{
info = (struct address *)malloc(sizeof(struct address));
// check here to see if memory was allocated

gets(info->name);
// if user enters null break out of for loop
gets(info->location);

// call another function here to create a link list in sorted
order(sorting based on name)

}
}

void printlist()
{
// print all the data user has entered
}

I don't see a free call anywhere. You guys mentioned to put free call
for every call to malloc but when I do that inside the for loop I end
up losing my data and when I try to print the list program crashes. I
guess my question is where to put the free call? And how would I know
how many times user entered data to match the number of malloc calls?
My guess is because it is only one pointer that is using malloc. By
calling free(info) will reclaim memory for ALL the malloc calls made.
But the only thing throwing me off is you guys mentioned free for
every malloc. Please help.


To decide where to put the free calls you have to know when the data is no longer needed. It is possible that the data is needed throughout the life of the program, in which case you would find some place where the program is closing down (such as just before main() returns).

For a structure such as your linked list you would write a loop that steps through the structure, extracts each pointer to an info, then does free() with that pointer.

It is possible your book did not bother to do this. If the allocations are not freed at end-of-program then the operating system does reclaim the memory after your program has exited. However, this is rather bad practice. The debugging environment is capable of detecting such "memory leaks" in a debug build, and leaving things allocated at the end defeats this helpful tool.

.

Relevant Pages

  • Malloc statistics patch
    ... Now that the UMA changes to use critical sections instead of per-cpu mutexes ... memory allocation patch previous posted. ... - Introduce per-cpu malloc type statistics, ... - If we're willing to abandon 5.x backport, we can clean up 'struct ...
    (freebsd-performance)
  • Re: #define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))
    ... The intent is to wrap raw memory allocation of N bytes ... return and accept void*. ... to use above macro than raw malloc. ... struct Child; ...
    (comp.lang.c)
  • Re: The annotated annotated annotated C standard part 3
    ... Beautiful Code, written in 1990, for memory allocation) is destroyed ... When the ability to use language is so checked by the ... You could avoid a problem I understand exists in malloc(), ... the caller to pass an instance of this struct. ...
    (comp.programming)
  • Re: Argument of free() should be const void*
    ... Doesn't malloc return void*? ... Changing the prototype of free to take a const-qualified pointer changes the ... it is quite common to wrap memory allocation calls with ...
    (comp.std.c)
  • Re: Array indexing
    ... However you can have an negative amount in your account. ... calculations of the sizes of memory objects may give negative results. ... malloc() takes an numerical type as its argument which must be an integer. ... void *malloc ...
    (comp.lang.c)