Path: utzoo!utgpu!attcan!uunet!oddjob!ncar!mailrus!um-math!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Malloc (was Re: Another great quote from Mr. Good)
Message-ID: <402@clio.math.lsa.umich.edu>
Date: 18 Aug 88 19:49:20 GMT
References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> <6339@chinet.UUCP>
Sender: usenet@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Distribution: comp
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 31
UUCP-Path: {mailrus,umix}!um-math!hyc

I get the feeling that there really is no solution at this point. How can you
have two different versions of Malloc/Free in the same system? Consider how
this would work. Assume a new ROM with TOS and GEMDOS that use the new, fixed
Malloc. Consider starting an old application from this new GEM desktop. Both
memory allocators will have to be rewritten to know exactly what each other
is doing, or you get programs tromping all over each other. And since you really
can't change the old version of Malloc, what you're really going to have to do
is write the new Malloc such that it allocates memory in such a way that the
old Malloc will honor its allocations. Anything using the old Malloc will still
eat up memory, will still need to be freed in the correct order or else you
lose. It'd be pretty gross. Having two incompatible memory allocators active
in the same system just can't be a good idea... It's not just a question of
a single program only sticking to one version - it's a question of many
programs being able to be loaded up arbitrarily, bearing in mind that the OS
itself is probably using the new allocator.

The only real solution would have been to put in the fixed allocator and tell
anyone with misbehaving code to rewrite it. Unfortunately, as Roy Good  has
mentioned, a lot of programs' original writers are no longer in business, so
there's no way to catch everything with an appropriate update. About the only
route then, if Atari put out a fixed Malloc, is for some Good Samaritan to
pull out a debugger and come up with some binary patches. Not exactly a nice
situation.


--
  /
 /_ , ,_.                      Howard Chu
/ /(_/(__                University of Michigan
    /           Computing Center          College of LS&A
   '              Unix Project          Information Systems