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)) #else # define slap_sl_alloca slap_sl_malloc # define slap_sl_freea slap_sl_free #endif
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.