peter@ficc.uu.net (Peter da Silva) (11/30/89)
In article <17377@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > In article <7132@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I take it you have never worked on a machine with a fixed-size stack. > and you've never seen a heap/stack collision. Yes, I've worked on a PDP-11. This is what usually happens: Heap gets close to stack. IF a large heap request comes first THEN it fails, malloc returns 0, and you can fall back. ELSE a large stack request comes first THEN you die. Moral: make large requests on the heap, where you can control what happens when they fail. > >And if your stack size is variable, then your big allocation can still > >increase your stack segment, and it's still never going to decrease. So you > >still lose there. > it also doesn't take care to properly align the return pointers and > a few other nasties. What doesn't? The hack I threw together for allot/forget? Sure. It's a brain-dead hack. I *said* it was a hack. That's an implementation detail. This isn't nuclear engineering, you know. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM