Path: utzoo!utgpu!attcan!uunet!oddjob!kaon!sphinx!gargoyle!att!chinet!saj From: saj@chinet.UUCP (Stephen Jacobs) Newsgroups: comp.sys.atari.st Subject: Re: Another great quote from Mr. Good Summary: If'n Malloc and Malloc1 can't be mixed... Message-ID: <6339@chinet.UUCP> Date: 18 Aug 88 14:40:06 GMT References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> Distribution: comp Organization: Chinet - Chicago Public Access UNIX Lines: 30 In article <1121@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > In article <692@auvax.UUCP} rwa@auvax.UUCP (Ross Alexander) writes: > } In recent articles, Roy J. Good @ Atari and others discuss the Malloc > } problem (qv). May I suggest the following solution: [a reasonable suggestion] > But this doesn't fix anything! The whole reason that Malloc is broken is > that you can't allocate an arbitrary number of blocks, because a static > area of memory is set aside for block descriptors. Any reasonable > malloc uses the blocks themselves to keep track (by using the space just > before or just after a free block as linkage to the next block), but we > can't do that because people keep messing with memory they don't own, > and so on. > > ============================================ > Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. > reflect those of Atari Corp. or anyone else. ...ames!atari!apratt The solution would seem to be to make it a guaranteed "feature" that any program trying to use both old and new versions of the storage allocator would die horribly. This isn't so different from the present universal behavior of buffered and unbuffered io to the same device: you'd best pick one and stick with it. There's some stuff like that concerning sensing mouse button states, too, I think (is that the same as buffered vs unbuff?) I'd like to agree with whoever it was that said you really shouldn't use the system memory allocator/deallocator enough to get into trouble with an 'improved' one, though. Library functions to manage small and/or frequent dynamic storage needs are 'friendlier' (to hardware, user and maintainer). Stuff like the arena management routines of MWC or the automatically garbage-collecting allocator that Free Software Foundation uses.