Kim_Sletten@MTSG.UBC.CA (02/13/90)
I am using Lattice C 5.2 function calloc() to dynamically allocate
memory as needed. And free() when no longer needed. These functions
seem to work as documented ie. free() does return a 0. However,
the free'd memory does not show up as being available until the
program terminates. Am I missing something?
Any help appreciated. Thanks.
Please direct replies to me. I will later summarize to the net.
____________________________________________________________________
Kim O. Sletten
Internet: Kim_Sletten@mtsg.ubc.ca
BITNET: USERSKIM@UBCMTSG
UUCP: ...!ubc-cs!mtsg.ubc.ca!Kim_Slettenwalker@sas.UUCP (Doug Walker) (02/16/90)
In article <2061540@mtsg.ubc.ca> Kim_Sletten@MTSG.UBC.CA writes: > > >I am using Lattice C 5.2 function calloc() to dynamically allocate >memory as needed. And free() when no longer needed. These functions >seem to work as documented ie. free() does return a 0. However, >the free'd memory does not show up as being available until the >program terminates. Am I missing something? The UNIX free() function is required to work in the following situation: for(s=head; s != NULL; s=s->next) free(s); This means that free() is required to 'hold on' to the most recently freed memory chunk until the next call to free(), or until the program exits. I suggest using AllocMem and remembering the length, or using AllocRemember. Either of these system-supplied memory allocators will work find and will not link in all the code required to do malloc() and free() from lc.lib. ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)471-6436 = *|. o.| || | o |// "I try to make everyone's day a little more surreal." ====== - Calvin (to Hobbes) usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
a218@mindlink.UUCP (Charlie Gibbs) (02/21/90)
[Various discussions as to the legality of such constructs as > for(s=head; s != NULL; s=s->next) free(s); deleted] Why take a chance? Being a "belt and suspenders" man myself, I prefer something like this: s = head; while (s != NULL) { x = s; s = s->next; free (x); } A bit of extra work, perhaps, but it's guaranteed to work even if the OS designer had a bad day. Of course, I'm the type who uses lots of extra parentheses just to play it safe, e.g. if ((x == a) && (y == b)) which won't break if I change the expressions. -- Charlie_Gibbs@mindlink.UUCP If you're not part of the solution, you're part of the precipitate.
reidc@eliot.UUCP (Reid Carson/Development) (02/21/90)
In article <1569@sas.UUCP>, walker@sas.UUCP (Doug Walker) writes: > In article <2061540@mtsg.ubc.ca> Kim_Sletten@MTSG.UBC.CA writes: > >the free'd memory does not show up as being available until the > >program terminates. Am I missing something? > > The UNIX free() function is required to work in the following situation: > > for(s=head; s != NULL; s=s->next) free(s); I believe this is not in fact correct. It is not portable to assume that a pointer to freed memory can still be dereferenced, even immediately after the call to free(). It works on many systems, yes, but not all. This was hashed out in comp.lang.c and/or comp.std.c a couple of months ago. In fact, it was even disputed whether it was proper to do comparisons with a pointer x after doing free(x). > This means that free() is required to 'hold on' to the most recently > freed memory chunk until the next call to free(), or until the program > exits. Free() is not required to hold on to the memory, it's just that the brk() and sbrk() calls on UNIX systems will increase your break point, but not decrease it. I don't recall if this is mandated by the SVID, but it's so much easier than trying to deal with the problems of returning an arbitrary chunk of memory to the OS that I would be surprised if any vendor had done otherwise. Evidently the Amiga OS has been implemented the same way. -- Reid W. Carson (uunet!pyrdc!eliot!reidc) - Unitech Software, Inc. What I tell you three times is true.