Andi,
Well, majority of the places where it is used right now can be abused through
user input.
PHP 4/5: overly long constant names defined(str_repeat("a", 1024 * 1024 * 6));
PHP5: overly long class & method names
PHP5: overly long function name
PHP5/Interbase: too many arguments passed to some functions.
PHP5/pcntl: too many arguments passed to pcntl_exec()
PHP5/wddx: long datetime field.
PHP5/SOAP: some instances where length is could be too long (if
request/response is doctored)
Ilia
On June 15, 2004 06:10 pm, you 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
