Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44135
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gravitonic.com from 209.85.222.199 cause and error)
Message-ID: <4A26DA21.1030703@gravitonic.com>
Date: Wed, 03 Jun 2009 13:16:33 -0700
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Matt Wilmas <php_lists@realplain.com>
CC:  internals@lists.php.net
References: <7435CCB5C8694BDCAAC90C165570A3E1@pc1>
In-Reply-To: <7435CCB5C8694BDCAAC90C165570A3E1@pc1>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] create_function/zend_eval_string aren't binary-safe
From: andrei@gravitonic.com (Andrei Zmievski)

Matt Wilmas wrote:
> Hi all,
> 
> I first noticed this with preg_replace()'s /e modifier (SO many other 
> issues with that...), but it also happens with create_function() and a 
> few other places where zend_eval_string() is used.  Other code 
> evaluation in PHP is binary-safe, so it seems like these areas should be 
> as well?  In case an example is needed:
> 
> $func = create_function('', "return strlen('Test\0string');");
> echo $func();
> 
> Patches:
> http://realplain.com/php/binary_eval_string.diff
> http://realplain.com/php/binary_eval_string_5_3.diff
> 
> Can they be applied?  (Also a small optimization by eliminating strlen() 
> usage.)  May want to verify the ext/interbase change.

Yes, apply them (though I didn't verify the interbase patch).

> I noticed there are several zend_eval_string() references in PECL 
> sources [1], which would be a problem after adding a string length 
> parameter...  How is that handled?  Should the updated function be 
> eval_stringL instead and add macros for compatibility?

I'd prefer that.

-Andrei