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() and other things Message-ID: Date: 12 Apr 91 19:34:57 GMT References: <1991Apr6.203939.8742@umiami.ir.miami.edu> <3278@charon.cwi.nl> <1991Apr7.224034.17484@cs.uow.edu.au> Sender: usenet@news.cs.brandeis.edu Organization: Symantec Corp. Lines: 32 In-Reply-To: risque@cs.uow.edu.au's message of 7 Apr 91 22:40:34 GMT In article <1991Apr7.224034.17484@cs.uow.edu.au> risque@cs.uow.edu.au (Peter Castle) writes: 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. Actually, free() only calls DisposPtr if the pointer you're freeing was allocated by NewPtr. Here's a (possibly non-working) translation of the assembly code into C: void free(short *p) { if (p) { /* if the pointer's not nil, */ p[-1] = ~p[-1]; /* toggle the tag word which occurs before the start of your block */ if (!p[-1]) /* if the tag is zero, */ DisposPtr(p); /* it's a Mac pointer, so free it */ } } 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. Yes, this is true. It's a bug, and will be fixed in the next major release. It may make you feel better to know that all structures allocated by ThC are rounded up to an even word boundry, so the only time this bug will catch you is if you're sorting characters or strings. -phil