Leisner.Henr@xerox.com (Marty) (04/22/89)
Is alloca really evil? The concept appeals to me -- a simple way to allocate space off the stack in the local stackframe which goes away when the function returns. The lack of portability and the seemingly pathological problems bother me (i.e. the calls to functions with alloca(n) as arguments). I'm debating whether to start using alloca in some of my applications. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
chris@mimsy.UUCP (Chris Torek) (04/23/89)
Alloca() is a poor-man's substitute for the language construct
f()
{
int n = expr();
char mem[n];
...
If dynamic stack declarations were supported directly by the language,
this sort of thing (now done with alloca) would be portable and
reasonable. Because it is not, alloca is not portable. In particular,
implementing alloca requires either compiler hooks or a limited
amount of compile-time optimisation.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrisgwyn@smoke.BRL.MIL (Doug Gwyn) (04/23/89)
In article <19255@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes: >I'm debating whether to start using alloca in some of my applications. We just went over that. alloca() is not available on some systems for good and sufficient reasons. I would think that any sane programmer would avoid it like the plague.
rbj@dsys.icst.nbs.gov (Root Boy Jim) (04/26/89)
? From: Doug Gwyn <gwyn@smoke.brl.mil>
? Date: 23 Apr 89 01:20:42 GMT
? In article <19255@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes:
? >I'm debating whether to start using alloca in some of my applications.
? We just went over that. alloca() is not available on some systems for
? good and sufficient reasons. I would think that any sane programmer
? would avoid it like the plague.
So they get your version. This seems to be a religious issue. It really
depends on your outlook. However, I would caution people to use it
only if they know *why* they are using it. Using alloca where malloc/free
would work as well is probably not a good idea. Likewise, bending over
backwards to force a problem into the malloc/free paradigm when it is
expressed more naturally in terms of alloca is merely being pedantic.
Root Boy Jim is what I am
Are you what you are or what?gwyn@smoke.BRL.MIL (Doug Gwyn) (04/26/89)
In article <19305@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: >? From: Doug Gwyn <gwyn@smoke.brl.mil> >? We just went over that. alloca() is not available on some systems for >? good and sufficient reasons. I would think that any sane programmer >? would avoid it like the plague. >So they get your version. No, my alloca() emulation doesn't work at all for some C implementations and it can be outwitted even on a "nice" architecture. It's strictly for emergency use if you don't have alloca() and run into code that relies on it, until you can get around to fixing the code. >Likewise, bending over backwards to force a problem into the malloc/free >paradigm when it is expressed more naturally in terms of alloca is merely >being pedantic. Avoidance of alloca() is NOT a matter of style (what you call a "religious issue"); it's a matter of practicality. malloc()/free() (also calloc() and realloc()) is the only portable method for dynamic storage allocation in C. If you want your code to be maximally portable, which I hope is normally the case, you must not rely on alloca().