alloca() problem

There is a rather nasty crash possible in PHP due to the usage of the alloca() function as can be demonstrated by bug #28064. Simpler bug replication case: php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); ' The problem is the result of missing checks to determine if alloca() had worked or not. The problem is further compounded by the fact that alloca() is a dangerous function that will not always return NULL on failure, making the return value check unreliable (read alloca manpage excerpt below). In PHP4 this function is only used about 7 times, while PHP5 uses it a little more frequently about 38 times. I think it would be best if do_alloca was made to use emalloc that can safely handle allocation failures. Alloca() is already an emalloc wrapper on Apple, HPUX, Windows, Netware. Excerpt from alloca manpage: NOTES ON THE GNU VERSION Normally, gcc translates calls to alloca by inlined code. This is not done when either the -ansi or the -fno-builtin option is given. But beware! By default the glibc version of <stdlib.h> includes <alloca.h> and that contains the line # define alloca(size) __builtin_alloca (size) with messy consequences if one has a private version of this function. The fact that the code is inlined, means that it is impossible to take the address of this function, or to change its behaviour by linking with a different library. The inlined code often consists of a single instruction adjusting the stack pointer, and does not check for stack overflow. Thus, there is no NULL error return. BUGS 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 Ilia