Bug #12668 Updated: unexpected behavior of preg_replace

ID: 12668 Updated by: andrei Reported By: chuck@1111-internet.com Status: Analyzed Bug Type: PCRE related Operating System: FreeBSD 4.0 PHP Version: 4.0.6 New Comment: I could change it so that only " and \ are slashed. From what I remember about some of the complaints before addslashes behavior was implemented, people had security concerns about using some external vars as parts of eval strings. If the vars contained some quotes, some unexpected or dangerous code could be evaluated.. Previous Comments: ------------------------------------------------------------------------ [2001-08-09 14:07:14] chuck@1111-internet.com Ah - I see - so what I'm seeing is actually a symptom of the basic issue that addslashes() is not a perfect reciprocal to putting addslashes-affected characters inside a string - i.e.: <?php // double-quoted strings echo "\""; // produces " echo "\\"; // produces \ // but echo "\'"; // produces \' // single-quoted strings echo '\''; // produces ' echo '\\'; // produces \ // but echo '\"'; // produces \" ?> whereas in mysql: select "\""; # produces " select "\\"; # produces \ select "\'"; # produces ' and perl is yet again different (with strings in single-quotes anyway): print "\""; # produces " print "\\"; # produces \ print "\'"; # produces ' print '\''; # produces ' print '\\'; # produces \\ print '\"'; # produces " I suppose backward compatibility would prevent this core behavior from being changed at this stage - it's just kinda screwy that both single-quoting and double-quoting of strings is a bit of a compromise in terms of slashed characters. Perhaps instead of sending preg_replace carry-forward values through the entire addslashes routine, only " and \ could be returned as slashed, and users could stick with using double-quotes for strings within the (eval'd) replace string... that would prevent people from having to use a hack get it to work as expected. Thanks, Chuck ------------------------------------------------------------------------ [2001-08-09 09:19:18] alindeman@php.net of course I meant addslashes() ------------------------------------------------------------------------ [2001-08-09 09:18:47] alindeman@php.net how about creating either two different functions, or another attribute to preg_replace, that you can set true/false to run that add_slashes or not? ------------------------------------------------------------------------ [2001-08-09 09:03:31] andrei@php.net This is because preg_replace() runs addslashes() internally on the captured subpatterns before substrituting them into the replacement string. It didn't used to but a few people complained that it was really hard to pass $n to a function because of single and double-quote conflicts. To be frank, I'm not sure how to solve this problem adequately, one group of people want the addslashes() run, the other one doesn't. ------------------------------------------------------------------------ [2001-08-08 21:06:50] chuck@1111-internet.com Simple problem - the script: <?php echo preg_replace("/'/e", "\"$0\"", "'"); // that's double-quote, slash, single-quote, slash, e, double-quote // then double-quote, escaped double-quote, $0, escaped double-quote, double-quote // then double-quote, single-quote, double-quote // meaning = "replace all occurrences of single-quote with the same string matched during the search - i.e. single-quote" ?> should produce one plain single-quote, but instead it produces an escaped single-quote. No other character seems to exhibit this behavior. Configuration: './configure' '--prefix=/usr/local/php4' '--with-mysql' '--with-apxs=/usr/local/sbin/apxs' '--enable-track-vars' '--with-gd=/usr/local' '--with-zlib-dir=shared' '--with-ttf' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-tiff-dir=/usr/local' '--with-mcrypt' '--with-pdflib' No other unusual configuration setups ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=12668&edit=1