Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: of course!
Summary: heap/stack collision go BOOM!
Message-ID: <17377@rpp386.cactus.org>
Date: 29 Nov 89 06:45:07 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>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 20

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.

>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.

the solution is to only use the right amount of memory in the first
place.  whether it comes off the heap or the stack seems immaterial
if they both share the same small address space.
-- 
John F. Haugh II                        +-Things you didn't want to know:------
VoiceNet: (512) 832-8832   Data: -8835  | In Ham lingo DEC is rot-13 for "Low
InterNet: jfh@rpp386.cactus.org         | Power".  "CPU?"  "QRP Vax-11."
UUCPNet:  {texbell|bigtex}!rpp386!jfh   +--------------------------------------