Re: Runtime stack allocation
- From: Keith Thompson <kst-u@xxxxxxx>
- Date: 30 Jun 2008 10:03:06 -0700
Stephen Sprunk <stephen@xxxxxxxxxx> writes:
[...]
malloc()/free() should be fast enough, even if it doesn't "feel" like
the right tool for the job. If not, can you use a VLA? If not, does
your system offer alloca()? Any of those are better than subverting
the compiler (and portability) and confusing people who will read your
code later by using inline assembly.
Yes, but alloca() isn't much better. Quoting the alloca man page on
one system:
The alloca function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
On many systems alloca cannot be used inside the list of
arguments of a function call, because the stack space reserved
by alloca would appear on the stack in the middle of the space
for the function arguments.
And VLAs have the drawback that there's no way to check whether the
allocation succeeded.
Use malloc(), and remember to free() the space when you're done with
it.
--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.
- References:
- Runtime stack allocation
- From: kid joe
- Re: Runtime stack allocation
- From: Stephen Sprunk
- Runtime stack allocation
- Prev by Date: Re: problem passing pointer array
- Next by Date: Re: Promoting unsigned long int to long int
- Previous by thread: Re: Runtime stack allocation
- Next by thread: Promoting unsigned long int to long int
- Index(es):
Relevant Pages
|
