Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!hsdndev!bbn.com!nic!news.cs.brandeis.edu!news!phils From: phils@chaos.cs.brandeis.edu (Phil Shapiro) Newsgroups: comp.sys.mac.programmer Subject: Re: THINK C's malloc(),free() help please Message-ID: Date: 12 Apr 91 18:14:31 GMT References: <1991Apr6.203939.8742@umiami.ir.miami.edu> <3278@charon.cwi.nl> Sender: usenet@news.cs.brandeis.edu Organization: Symantec Corp. Lines: 27 In-Reply-To: guido@cwi.nl's message of 7 Apr 91 14:01:43 GMT In article <3278@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: You describe that you malloc() some blocks, the free() them, then malloc() some more, and expect to see the same addresses being reused, but instead see higher addresses being generated. This could either be a bug in your program [...], or a result from the strategy used by malloc when allocating small blocks (I can imagine that freed blocks go to the end of a rather long free list, while new blocks are allocated out of its beginning). Actually, it's due to the fact that ThC uses a pretty simple method to allocate blocks of memory. It keeps track of the last place in the zone it looked at, and it starts looking for a free block of memory big enough there (it's called "startPtr"). This place isn't affected by freeing up blocks, so a freed block may not be reused for quite awhile. Freeing a block just changes its tag word to indicate that it's empty. I think that allocated blocks contain their size negated (~size) and free blocks just contain their size (or vice versa). So, free() just inverts the bits in the tag word to flag the block as free. Also, a free'd block may be combined with another free block if necessary. So, you may never see the original address again, even if it is reused. -phil