Howard Chu writes:
What problems are we signing up for by allowing use of alloca()?
This is from memory, and for all I know outdated:
It's somewhat unportable, and alloca from GNU something (gcc? glibc?)
is or was a malloc wrapper on systems where it cannot provide a proper
alloca(). So I think we'd need
#if <has a good alloca, and not making things worse by using malloc>
# define slap_sl_alloca(size, ctx) alloca(size)
# define slap_sl_freea(ptr, ctx) ((void) (ptr))
# define slap_sl_alloca slap_sl_malloc
# define slap_sl_freea slap_sl_free
Unlike variable-size arrays, alloca() memory lives to the end of the
function call. So avoid alloca() in loops. Be careful moving code
using alloca() into other functions. gcc seems unwilling to inline
functions using alloca, hopefully other compilers have similar sense.
I think it can be incompatible with variable-size arrays - in the
same stack frame, I presume. Which is all right when we stay
C90-compatible, but we may be moving on someday. That said, I think
some var-array implementations use/used alloca, so...
In any case, a more future-friendly way might be to invent a syntax to
declare "variable-sized arrays" that actually use sl_malloc or alloca
if the compiler doesn't support variable-sized arrays.