Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!cs.uow.edu.au!risque
From: risque@cs.uow.edu.au (Peter Castle)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C's malloc() and other things
Message-ID: <1991Apr7.224034.17484@cs.uow.edu.au>
Date: 7 Apr 91 22:40:34 GMT
References: <1991Apr6.203939.8742@umiami.ir.miami.edu> <3278@charon.cwi.nl>
Organization: Dept of Computer Science, Wollongong University
Lines: 34

guido@cwi.nl (Guido van Rossum) writes:

>(Question about what malloc and free do.)

>Don't worry, THINK C's malloc() and free() work fine.

I have had some trouble myself with Think C 4.0's malloc() and free().
Let me say what I think the problem is, and maybe some guru could respond.

If you ask for more than 15000 bytes, malloc() just uses NewPtr to get it.
However, if you want a smaller amount of memory, Think C asks for a
15000byte block and distributes smaller portions itself.  Thus if you ask
for lots of small amounts, only one call to NewPtr is made.

However, free() just calls DisposPtr, so each of these small portions are
released one at a time - never the whole 15000 bytes! So, if you ask for
say 14k bytes at a time, memory is fragmented by these 1k leftover bits
which are NEVER given back.

I just use NewPtr and DisposPtr directly, just as Think C V3.0 used to do.


A second problem:  Has anyone ever used qsort to sort odd length records?
Don't.  The code for qsort AUTOMATICALLY adds one to the odd length of such
records WITHOUT any warning.  Sure, it is protecting the user from possible
odd addresses being passed to the user's supplied comparison routine, but
surely the errors caused by such a call would be a dead giveaway for any
person silly enough to get such odd addresses.  I was sorting odd length
character records.


Peter Castle
Computer Science Dept
University of Wollongong