Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10445
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <24e5f3b704061409274fe18564@mail.gmail.com>
Date: Mon, 14 Jun 2004 09:27:09 -0700
To: ilia@prohost.org
Cc: internals@lists.php.net
In-Reply-To: <200406141210.46230.ilia@prohost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200406141138.30533.ilia@prohost.org> <40CDCCDF.2090201@php.net> <200406141210.46230.ilia@prohost.org>
Subject: Re: [PHP-DEV] Re: alloca() problem
From: sterling.hughes@gmail.com (Sterling Hughes)

On Mon, 14 Jun 2004 12:10:46 -0400, Ilia Alshanetsky <ilia@prohost.org> 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