Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AmigaGCC stack hogging
Keywords: GNU, alloca(), regex.c, alloca.c, gcc, g++
Message-ID: <17766@cbmvax.commodore.com>
Date: 17 Jan 91 23:30:41 GMT
References: <1882f287.ARN1979@moria.UUCP> <1991Jan14.212254.9779@csun.edu> <18887df5.ARN1ad7@moria.UUCP> <1991Jan17.141218.19953@zorch.SF-Bay.ORG>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 24

In article <1991Jan17.141218.19953@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>Maybe I'm missing the point here.  The _purpose_ of alloca() is to
>allow extremely low overhead grabbing and releasing of extremely
>temporary memory, and to do a super cheap form of resource tracking.
>
>Why replace it by putting back something that installs the very same
>problems alloca() was trying to solve, and possibly gets you into other
>trouble if code makes assumptions that things pushed on the stack and
>things alloca()ed on the stack are in consecutive storage locations?

	The problem is that GCC (and other gnu code) allocates LARGE
amounts of memory using alloca, and holds it for a long time.  For example,
I'm told that the preprocessor or compiler pulls entire files into a
single alloca and then operates on that structure.  this is a killer on
any OS without automatic stack extension.  Modifying alloca is far easier
when porting gnu code than trying to get the GNU people to modify the
original gnu source.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)