27 Feb
2017
27 Feb
'17
8:50 p.m.
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(a)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