So, oddly enough while responding to this, gmail is showing me Zend
advertisements - just thought you should know you are getting your
money's worth :)

I'll buy that alloca() is harmless in the places the executor uses it
(*), php segvs on highly recursive functions, worrying about overly
long function names won't keep anyone up at night.  But the real issue
is the other areas ilia mentions, where it just isn't worth it.

-Sterling
(*) Although I think its a bottom drawer optimization that something
like the Zend optimizer invalidates.

On Wed, 16 Jun 2004 01:10:16 +0300, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 
> Ilia,
> 
> alloca() is very important for the executor loop and functions which where
> performance is very important (mainly the Zend Engine).
> I don't see any convincing reason not to use it in the way it is being used
> today. If there are any specific places you find problematic and want to
> discuss let me know.
> 
> Andi
> 
> At 12:10 PM 6/14/2004 -0400, Ilia Alshanetsky 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.
> >
> >Ilia
> 
> 
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to