Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: of course!
Message-ID: <11674@smoke.BRL.MIL>
Date: 23 Nov 89 16:09:15 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>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1989Nov22.224209.28911@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>Unless the program is using *lots* of memory and stack space, there is very
>little likelihood of overflowing the stack.

Many implementations have severe constraints on stack size.  For example,
on Gould PowerNode series running UTX-32 (based on 4.3BSD), the stack
size is fixed at link time, typically only a few kilobytes.  Allocating
large auto arrays can easily cause the stack limit to be exceeded.

The three major alternatives are:
	auto arrays, with the problem just mentioned
	static arrays, which waste program data space
	malloc()ed storage, which costs more time.

In most situations I would opt for the latter.