Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.lang.c
Subject: Re: alloca() portability
Keywords: portability, alloca
Message-ID: <1990Nov09.233527.7489@chinet.chi.il.us>
Date: 9 Nov 90 23:35:27 GMT
References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu>
Organization: Chinet - Public Access UNIX
Lines: 33

In article <27537@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:

>All in all, I would say that the threat of failure (from optimizing
>compilers) plus that of nonportability (to environments where not even
>a mallocking alloca can be used) far outweigh the convenience of
>not having to call free().  All that is left is the difference in
>speed, and there are simple ways around that problem as well.

The usual "simple" way goes something like this:

#define BIG_BUFF 1024  /* that should be big enough */

work(str)
char *str;
{
   buffer[BIG_BUFF);
   strcpy(buffer,str); /*  make a local copy to manipulate */
   ....
}

This does handle recursion and longjmp()'s out of signal handlers with
a lot less work than a malloc() based solution and it could even be
kept from crashing at random if a length check were added, but there
is no guarantee that an entire string can be manipulated.  It just
leaves the nagging feeling that something necessary was omitted from
the language....

The argument that alloca isn't a requirement because it's little-used
(and it's little-used because its not required) doesn't help much
either.

Les Mikesell
  les@chinet.chi.il.us