collinge@uvicctr.UUCP (Doug Collinge) (08/20/88)
>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 ... but we >can't do that because people keep messing with memory they don't own, >and so on. > -- Allan Pratt, Atari Corp. Actually, I've always hated the way unix malloc works; too dangerous, you see, someone could easily write all over the links, then all hell breaks loose especially in a system with no protection. Why not keep the block parameters in tables somewhere else? Maybe even The Kernel could keep them in Protected Memory and thus have global memory allocation (and fragmentation). I digress... Suggestion: Keep the Malloc tables in Malloced blocks, all chained together and squished once in a while. It makes your algorithms a touch more complicated and thus slower but you wanted regressive compatibility and who expects malloc and friends to be fast? With this method you could have a switch somewhere: Regressive Position - acts exactly like the old broken Malloc as long as possible then starts breaking dusty decks - anything that used to work should still work and some things will work longer; Progressive Position - allocates memory as efficiently as possible. Historic developers of the dusty decks will use the default Regressive Position by not doing anything; some old programs may even work better through not making silly assumptions and getting more memory out of the new, compatible, Malloc. Modern developers also do nothing and get the Progressive Mode courtesy of the latest versions of C runtime startup code, which make some new OS call. Comments Atari? I'm no OS guru - I must have overlooked something... -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 collinge@uvunix.BITNET decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge