🚀 go-pugleaf

[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
<the-known-world>!alberta!auvax!rwa