Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!psuvax1!rutgers!texbell!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.wizards Subject: Allocation on stack versus from heap. Re: of course! Message-ID: <7152@ficc.uu.net> Date: 29 Nov 89 21:21:38 GMT References: <152@norsat.UUCP> <2586@unisoft.UUCP> <15769@bloom-beacon.MIT.EDU> <17264@rpp386.cactus.org> <4526@ski.cs.vu.nl> <17303@rpp386.cactus.org> <1051@root44.co.uk> <1989Nov22.224209.28911@athena.mit.edu> <7132@ficc.uu.net> <17377@rpp386.cactus.org> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 32 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 . 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM