ID: 40395
User updated by: jfrim at idirect dot com
Reported By: jfrim at idirect dot com
Status: Assigned
Bug Type: PCRE related
Operating System: *
PHP Version: *
Assigned To: andrei
New Comment:
The following code demonstrates 0x00 and 0x22 being escaped, without
0x5C being escaped.
It creates an 8-bit ASCII text output, with the character value (in
DECIMAL) enclosed within braces (except for escaped chars, in which
case it ends up as "92"), followed by the actual character, then a
CRLF, for all 256 characters.
Note how the backslash (0x5C, decimal 92) is NOT escaped, and contrary
to what [EMAIL PROTECTED] posted, the single-quote (0x27, decimal 39) is
NOT escaped either. (The double-quote (0x22, decimal 34) is escaped
instead.)
<?php
header('Content-Type: text/plain; charset=US-ASCII');
header('Content-Disposition: inline; filename=PCRE.txt');
header('Pragma: no-cache');
header('Expires: 0');
header('Cache-Control: no-cache; must-revalidate');
$teststring='';
for ($i=0; $i<=255; $i++) {
$teststring.=chr($i);
}
echo
preg_replace('/([\\x00-\\xFF])/e',"'{'.ord('\\1').'}\\1'.chr(13).chr(10)",$teststring);
?>
Previous Comments:
------------------------------------------------------------------------
[2007-02-08 19:47:10] jfrim at idirect dot com
I have verifed that along with 0x00 being escaped, 0x22 (the
double-quote character) is also escaped. No other byte values are
affected.
Even if the documentation was changed to reflect this escaped behaviour
of 0x00 and 0x22, there would still be a bug with this behaviour since
0x5C (the backslash character) is NOT escaped!
This would create a discrepency problem if the input string to a
preg_replace() contained a literal backslash followed by a number zero,
or a backslash followed by a double-quote. There would be no way to
tell from the resulting preg_replace'd data if those sequences are
escaped NULLs and escaped double-quotes, or if those were literal
sequences in the input string.
So the only way to fix this bug is to either...
...A: Escape the backslash as well, and change the documentation to
state that 0x00, 0x22, and 0x5C are escaped, or...
...B: Do not escape any characters.
I would say method B is preferred, since no stripslashes() would have
to be performed on the resulting output from a preg_replace(), and it's
far more intuitive to always know that a regular expression
back-reference will always contain the exact byte value that was
matched, without having to worry about special exceptions.
------------------------------------------------------------------------
[2007-02-08 13:17:59] [EMAIL PROTECTED]
Ok, so the problem here is that preg_do_eval() calls
php_addslashes_ex(), that escapes "'", "\" and "\0".
So we should either not escape the \0 or reflect the behaviour in the
docs.
Assigning to the extension maintainer.
------------------------------------------------------------------------
[2007-02-08 06:01:32] jfrim at idirect dot com
I'd also like to present bug #16590:
http://bugs.php.net/bug.php?id=16590
Note the following example they list as a SOLUTION to specifying NULLs
in the pattern:
preg_match("/\\x00/", "foo\0bar")
And note the following statement from bug report #16590:
"...The docs state that PCRE is binary safe..."
So if PCRE is binary safe, and you can specify NULLs in the pattern
with \x00, why are back references unable to return these matched
NULLs?!?!?
How is this NOT a bug?!??
------------------------------------------------------------------------
[2007-02-08 05:32:20] jfrim at idirect dot com
If the regular expression were /([\x00-\xFF])/ , you would think EVERY
possible byte value would be matched. In fact, all of them do get
matched. However, all of them EXCEPT for byte value 0x00 is returned
in the \1 back reference. Any 0x00 bytes are returned as two bytes,
0x5C followed by 0x30.
I have not found in any Perl regular expression documentation an
explanation for why the 0x00 byte is handled like this, so could you
please tell me why this is NOT a bug with PCRE.
Thanks.
------------------------------------------------------------------------
[2007-02-08 00:26:14] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
------------------------------------------------------------------------
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/40395
--
Edit this bug report at http://bugs.php.net/?id=40395&edit=1
