Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.151.69.1 cause and error)
Message-ID: <7435CCB5C8694BDCAAC90C165570A3E1@pc1>
To: <internals@lists.php.net>
Date: Wed, 3 Jun 2009 13:45:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: [PATCH] create_function/zend_eval_string aren't binary-safe
From: php_lists@realplain.com ("Matt Wilmas")

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.

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?

[1] http://lxr.php.net/ident?i=zend_eval_string


Thanks,
Matt