#12668 [Ana->Bgs]: unexpected behavior of preg_replace

ID: 12668 Updated by: iliaa@php.net Reported By: chuck@1111-internet.com -Status: Analyzed +Status: Bogus Bug Type: PCRE related Operating System: FreeBSD 4.0 PHP Version: 4.0.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: ------------------------------------------------------------------------ [2002-06-09 01:15:26] xuefer@21cn.com before this problem is solved use preg_replace_callback instead it's a nice function :) ------------------------------------------------------------------------ [2002-06-04 15:15:51] bernard.sumption@spc.ox.ac.uk I have the same problem, but the nature of the material I'm working on makes it hard to simply strip offending chars from the stings before running preg_replace, which would be the easiest solution. I vote for an additional pcre modifier to turn off magic quotes. Bernie :o) ------------------------------------------------------------------------ [2002-02-26 10:39:56] michielu@gimo.dhs.org I use the phplib template functions and apparently that library uses the preg_replace routines as well. Whenever I try to put slash-quote data through this template library it gets stipslashes it seems. The problem boils down to: preg_replace("/key/", '\' \\\' \\\\\'', "replacekeyvalue"); which should yield: replace' \' \\'value but yields replace' \' \'value This used to work properly in 4.0.4, but now it seems I have to preparse user input, replace \' and \\ with something else, run preg_replace and repatch the \' and \\ values. This is unworkable! I'd vote for a configuration variable to fix this. Something in line with magic_quotes_gpc and magic_quotes_sybase. Perhaps magic_quotes_pcre? ------------------------------------------------------------------------ [2001-08-31 11:12:50] andrei@php.net 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.. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/12668 -- Edit this bug report at http://bugs.php.net/?id=12668&edit=1