Thanks for the stak.c it's a good idea. I'm not sure about the stack freeing routine at the end of the file as it seems to rely on a bit of pointer voodoo but I think I could rationalize all that.
cheers, Nick

On Feb 28, 2017 1:33 AM, "Derek Fawcus" <dfawcus+lists-tuhs@employees.org> wrote:
On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote:
> I've been having a bit of trouble with /bin/sh (Bourne's original one)
> for the same reason.
 [snip]
> Trouble is, this makes a non-stdio-using program be
> stdio-using, in the worst case it's a non-stdio-using program that has
> its own malloc() based on sbrk()... so we get another malloc()
> happening in the middle, I temporarily fixed this by redirecting the
> modern system's malloc() into the ancient system's malloc() but this
> is a very non desirable solution. As another possibility I was
> thinking of changing the ancient system's sbrk() into realloc() and
> implementing a routine to relocate the heap, it obviously would have
> to understand everything on the heap and everything that can point
> into it.

How about applying Geoff Collyer's change to the shell memory management
routine available here:

    http://www.collyer.net/who/geoff/stak.port.c

DF