On Mon, 14 Jun 2004 12:10:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: > > Virtually all current uses involve some form of user input, which means that > the user can exploit the problem. When bar[2048] is used to create a buffer > of a certain known size that never change, with alloca a buffer of undermined > size is created in most cases. > > The only 'safe' way to use the function would be to put it inside a wrapper > that would check the size against some preset limit and based on that > determine if alloca or emalloc should be used. The length would also need to > be stored to allow the free wrapper to determine if efree() is needed. These > safety checks may offset the miniscule speed advantage gained by using alloca > anyway, especially when the length is being calculated inside alloca call. >
Calling malloc is generally not that expensive as you would hope that the operating system would give you reasonable locality in the cases where i've seen alloca() used. Doing a stack size check is still dangerous, simply because you don't know what has been previously allocated off the stack, nor do you know what will be allocated off the stack further down within the function. Calling do_alloca() to avoid a heap access is a bottom drawer optimization, and yields very little when it comes to improving php's memory usage patterns (as opposed to a fix block allocator)... ie, i agree with ilia - it should just be hosed. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
