Path: utzoo!attcan!uunet!husc6!mailrus!cornell!uw-beaver!ubc-cs!alberta!auvax!rwa From: rwa@auvax.UUCP (Ross Alexander) Newsgroups: comp.sys.atari.st Subject: Re: Another great quote from Mr. Good Summary: Malloc problem suggestion... Message-ID: <692@auvax.UUCP> Date: 16 Aug 88 08:45:40 GMT References: <1116@atari.UUCP> Distribution: comp Organization: Athabasca U., Alberta, Canada Lines: 37 [fancy line-eater line down for preventative maintenance; call later] In recent articles, Roy J. Good @ Atari and others discuss the Malloc problem (qv). May I suggest the following solution: 1) build a proper version of Malloc (MallocP for "malloc patched" comes to mind). Assign it a TOS-call number, and give it reasonable semantics; Un*x semantics are as reasonable as any [ :-) :-) ]. 2) use this reasonable allocator as a foundation for a version broken in exactly the same ways as the current TOS version. That is, it obeys the assumptions that people are making about the current allocator (that it's okay to exceed your chunk, that chunks are contiguous, et al.), and make this broken allocator available through the old TOS-call number. 3) encourage people to use the new allocator; they will because it's no longer broken, right ? 4) after a while, make the old entry point go away (if you want). Now, this may be a little tricky. You might have to compromise some functionality in the back-compatibility entry-point version. For instance, it might be only able to allocate 1/3 or 1/2 of the total available free memory (here's a reason to use the upgraded entry point :-). I don't know if this is THE answer, but it might be AN answer. Comments ? -- Ross Alexander @ Athabasca University!alberta!auvax!rwa