Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!pcsbst!jkh From: jkh@bambam.pcs.com (Jordan K. Hubbard) Newsgroups: comp.sys.amiga.programmer Subject: Re: AmigaGCC stack hogging Message-ID: Date: 29 Jan 91 04:04:42 GMT References: <1882f287.ARN1979@moria.UUCP> <1991Jan14.212254.9779@csun.edu> <18887df5.ARN1ad7@moria.UUCP> <1991Jan17.141218.19953@zorch.SF-Bay.ORG> Sender: news@pcsbst.pcs.com Organization: PCS Computer Systems, GmbH Lines: 49 In-reply-to: xanthian@zorch.SF-Bay.ORG's message of 17 Jan 91 14:12:18 GMT >> As I pointed out in my previous article, along with the GNU sed, flex, >> diff, and gawk Amiga ports followed a version of alloca() that does >> _not_ allocate on the stack, _but_ uses malloc()! The other day I just >> checked, and this alloca.c module is also included with the gcc-1.37.1 >> >Maybe I'm missing the point here. The _purpose_ of alloca() is to >allow extremely low overhead grabbing and releasing of extremely >.. [etc etc] >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? > >If the gnu code is doing inappropriate things with alloca() replace the >calls with malloc() calls explicitly. Otherwise you are just creating ARGH! NO! NO! I'm afraid you _are_ missing the point, Kent. While you're right in saying that the primary purpose of alloca() is to provide low overhead you-don't-need-to-worry-about-freeing-it-afterwards allocation of memory, just replacing the calls to alloca() with malloc() IS NOT a good solution to the problem! Unless you then take the time to track the memory so allocated and explicitly free() it at the appropriate time, you've just introduced a memory leak. Tracking the memory properly may not be all that easy if the original programmer used alloca() specifically because such tracking was highly non-trivial otherwise. The alloca.c file that Per mentions was written in an attempt to emulate alloca() for machines that don't support the actual stack manipulation for some reason. While it's true that it actually uses malloc() to do its work, it would be a mistake to assume that it's simply a lexical replacement. It actually tries quite hard to keep track of what was allocated at what time so that it can free things automatically for you when it's quite sure that you've returned from an "alloca()" using routine. The algorithm isn't perfect, given the constraints it has to work under, but it's a whole lot better than a simply dropping malloc() in place of alloca(). Performance certainly won't be the same as with a _real_ alloca(), sure, but I find memory leaks a whole lot more objectionable than lost CPU cycles! Jordan -- PCS Computer Systeme GmbH, Munich, West Germany UUCP: pyramid!pcsbst!jkh jkh@meepmeep.pcs.com EUNET: unido!pcsbst!jkh ARPA: jkh@violet.berkeley.edu or hubbard@decwrl.dec.com