Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: ilia@prohost.org
To: internals@lists.php.net
Date: Mon, 14 Jun 2004 12:10:46 -0400
User-Agent: KMail/1.6.1
References: <200406141138.30533.ilia@prohost.org> <40CDCCDF.2090201@php.net>
In-Reply-To: <40CDCCDF.2090201@php.net>
Organization: Prohost.org
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <200406141210.46230.ilia@prohost.org>
Subject: Re: [PHP-DEV] Re: alloca() problem
From: ilia@prohost.org (Ilia Alshanetsky)

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