«

In the course of an assignment, I learned the hard way that I shouldn't try
to free a malloc'd member of a malloc'd structure after having freed that
structure (i.e., free( structure ); free( structure->bufferspace ) ).

My question is, if I free just the structure, will the (e.g.) bufferspace be
freed implicitly, or do I have to (as I currently am) free the members
first?

Thanks.
-cjl

John wrote:
> In the course of an assignment, I learned the hard way that I shouldn't try
> to free a malloc'd member of a malloc'd structure after having freed that
> structure (i.e., free( structure ); free( structure->bufferspace ) ).
>
> My question is, if I free just the structure, will the (e.g.) bufferspace be
> freed implicitly, or do I have to (as I currently am) free the members
> first?

Free the members first. Information about subsequent allocation of
members is not magically incoded into the information about the
structure allocation.

John wrote on 30/07/04 :
> In the course of an assignment, I learned the hard way that I shouldn't try
> to free a malloc'd member of a malloc'd structure after having freed that
> structure (i.e., free( structure ); free( structure->bufferspace ) ).
>
> My question is, if I free just the structure, will the (e.g.) bufferspace be
> freed implicitly, or do I have to (as I currently am) free the members
> first?

"All what have been done must be undone".

IOW, yes, you have to free the innermost elements first. There is no
implicit automatic mecanism that frees the memory in C.

That said, you can write a pair of function known as 'creator /
destructor' that helps to create / delete the objects properly and hide
some gory details the user is not supposed to deal with.

myobj_s *myobj_create (void);
void myobj_delete (myobj_s *this);

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

Martin Ambuhl wrote:

> John wrote:
> > In the course of an assignment, I learned the hard way that I shouldn't try
> > to free a malloc'd member of a malloc'd structure after having freed that
> > structure (i.e., free( structure ); free( structure->bufferspace ) ).
> >
> > My question is, if I free just the structure, will the (e.g.) bufferspace be
> > freed implicitly, or do I have to (as I currently am) free the members
> > first?
>
> Free the members first. Information about subsequent allocation of
> members is not magically incoded into the information about the
> structure allocation.

Ah, but what if some other structure is also pointing to one of those members? Do
you keep a count of the number of items pointing to that member, and decrement
when you might free it until it reaches 0, then free it?...

"Wayne Rasmussen" <> wrote
>
> Ah, but what if some other structure is also pointing to one of those
> members? Do you keep a count of the number of items pointing to that
> member, and decrement when you might free it until it reaches 0, then free
> it?...
>
You've got to be disciplined. The general rule is that only one pointer
should exist in long-term storage (obviously you must take copies to pass to
subroutines, or for local manipulations).
With some data structures, like linked lists, this isn't possible.
Inherently there are two pointers to each node of a doubly-linked list. So
you must define an object as "my doubly linked list data structure" and then
write functions which will manipulate it, and especially destroy it, in a
controlled way. Once the list is destroyed, all the pointers to data nodes
should go with it.

On 30 Jul 2004 13:43:38 EDT, Wayne Rasmussen
<> wrote:

>
>
>Martin Ambuhl wrote:
>
>> John wrote:
>> > In the course of an assignment, I learned the hard way that I shouldn't try
>> > to free a malloc'd member of a malloc'd structure after having freed that
>> > structure (i.e., free( structure ); free( structure->bufferspace ) ).
>> >
>> > My question is, if I free just the structure, will the (e.g.) bufferspace be
>> > freed implicitly, or do I have to (as I currently am) free the members
>> > first?
>>
>> Free the members first. Information about subsequent allocation of
>> members is not magically incoded into the information about the
>> structure allocation.
>
>Ah, but what if some other structure is also pointing to one of those members? Do
>you keep a count of the number of items pointing to that member, and decrement
>when you might free it until it reaches 0, then free it?...
>
Well, first you review your design, because there is probably a better
way to do it

But if you must, yes, reference counters are a common way to handle
the situation.

--
Al Balmer
Balmer Consulting

Alan Balmer wrote:

> On 30 Jul 2004 13:43:38 EDT, Wayne Rasmussen
> <> wrote:
>
> >
> >
> >Martin Ambuhl wrote:
> >
> >> John wrote:
> >> > In the course of an assignment, I learned the hard way that I shouldn't try
> >> > to free a malloc'd member of a malloc'd structure after having freed that
> >> > structure (i.e., free( structure ); free( structure->bufferspace ) ).
> >> >
> >> > My question is, if I free just the structure, will the (e.g.) bufferspace be
> >> > freed implicitly, or do I have to (as I currently am) free the members
> >> > first?
> >>
> >> Free the members first. Information about subsequent allocation of
> >> members is not magically incoded into the information about the
> >> structure allocation.
> >
> >Ah, but what if some other structure is also pointing to one of those members? Do
> >you keep a count of the number of items pointing to that member, and decrement
> >when you might free it until it reaches 0, then free it?...
> >
> Well, first you review your design, because there is probably a better
> way to do it
>
> But if you must, yes, reference counters are a common way to handle
> the situation.

Sure, good design should be done first. But this is more of the what if variety.
Actually, was curious to see other ways people might deal with this. Other than good
design, what would be the other common ways? Having a master array of that type for
example.

Not looking to create a garage collector either!


cya,
wayne

Malcolm wrote:

> "Wayne Rasmussen" <> wrote
> >
> > Ah, but what if some other structure is also pointing to one of those
> > members? Do you keep a count of the number of items pointing to that
> > member, and decrement when you might free it until it reaches 0, then free
> > it?...
> >
> You've got to be disciplined. The general rule is that only one pointer
> should exist in long-term storage (obviously you must take copies to pass to
> subroutines, or for local manipulations).
> With some data structures, like linked lists, this isn't possible.
> Inherently there are two pointers to each node of a doubly-linked list. So
> you must define an object as "my doubly linked list data structure" and then
> write functions which will manipulate it, and especially destroy it, in a
> controlled way. Once the list is destroyed, all the pointers to data nodes
> should go with it.

Well, doubly linked lists are a special case for sure.

I was trying to think of a good example, like say a chess board where you would
want to try some search with alpha-beta and backtracking. But in those cases,
you really should be making copies of game board and everything it refers to or
at least, have a way to get back to the previous position when backtracking.

Then I was thinking of a DB, where you might have different links say to a
zipcode table record, but ideally there should be one path to get to that
information should there?

If you were doing your own garbage collector you might have to worry about this.

John wrote:

> In the course of an assignment, I learned the hard way that I shouldn't try
> to free a malloc'd member of a malloc'd structure after having freed that
> structure (i.e., free( structure ); free( structure->bufferspace ) ).
>
> My question is, if I free just the structure, will the (e.g.) bufferspace be
> freed implicitly, or do I have to (as I currently am) free the members
> first?

huh, if only that was true (freeing members implicitly), there
would be less memory leaks on earth. Unfortunately it is not true.

You got two problems:-
smaller one: your memory access is likely to cause seg. fault ( you are
going out of the address space of the process).

bigger one: memory leak.

Pointer is nothing but a variable that stores an address. The
moment you do a free(structure), the memory pointed to by that address
is reclaimed by the GC ( in other words, that could be used again by the
memory manager in the future). But the info. to delete
sturucture->bufferspace has already been freed by your previous
statement. So you won't find the address that ought to be removed as far
as 'structure->bufferspace' is concerned.


Try to group the malloc/free in a function as far as possible. It
would help you to get rid of memory leaks ( and anyone who had to
read/maintain would be thankful to you for that).

HTH.

- Karthik.

Wayne Rasmussen wrote:

>
> Martin Ambuhl wrote:
>
>
>>John wrote:
>>
>>>In the course of an assignment, I learned the hard way that I shouldn't try
>>>to free a malloc'd member of a malloc'd structure after having freed that
>>>structure (i.e., free( structure ); free( structure->bufferspace ) ).
>>>
>>>My question is, if I free just the structure, will the (e.g.) bufferspace be
>>>freed implicitly, or do I have to (as I currently am) free the members
>>>first?
>>
>>Free the members first. Information about subsequent allocation of
>>members is not magically incoded into the information about the
>>structure allocation.
>
>
> Ah, but what if some other structure is also pointing to one of those members? Do
> you keep a count of the number of items pointing to that member, and decrement
> when you might free it until it reaches 0, then free it?...


In my humble opinion having foriegn structure members point to other
structure members is just bad programming design. Loose coupling and
tight cohesiveness is not only desirable for coded functions, but for
data too. As to the issue of freeing malloc'd members I would suggest,
at the very least, to have a dedicated function to free all the members,
then free the structure last of all.

Regards,
Stan Milam.