Req #76124 [NEW]: Better way to detect PCRE errors such as invalid patterns
| From: | graefrath at femu dot rwth-aachen dot de | Date: | Wed, 21 Mar 2018 11:53:52 +0000 |
| Subject: | Req #76124 [NEW]: Better way to detect PCRE errors such as invalid patterns | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-214426@lists.php.net to get a copy of this message | ||
From: graefrath at femu dot rwth-aachen dot de
Operating system:
PHP version: Irrelevant
Package: PCRE related
Bug Type: Feature/Change Request
Bug description:Better way to detect PCRE errors such as invalid patterns
Description:
------------
preg_match returns false in case of an error. However, not all errors
that can occur have corresponding error codes returned by
preg_last_error. Additionally, the last error is not cleared when a PCRE
function is called and there is no function to manually clear it. This
makes it very hard to reliably detect errors such as invalid patterns.
Consider the following example:
@preg_match("/./u", "\xff"); // returns false and sets preg_last_error
to PREG_BAD_UTF8_ERROR
@preg_match("invalidpattern", ""); // returns false, but preg_last_error
is still PREG_BAD_UTF8_ERROR
The only way to detect the invalid pattern error is to catch the PHP
warning that is being raised. This seems really inconsistent to me.
Since PHP < 7 does not have error_clear_last yet, it is also not trivial
to figure out whether you have to look at the last PHP error or the last
PCRE error, since a PHP error message starting with preg_ could also be
from a previous call.
Expected result:
----------------
I expect the return value of preg_last_error to reflect all kinds of
errors correctly, not just some of them.
Actual result:
--------------
preg_last_error returns a valid error code only for some errors, while
other are indicated by PHP warnings.
--
Edit bug report at https://bugs.php.net/bug.php?id=76124&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=76124&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=76124&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=76124&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=76124&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=76124&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=76124&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=76124&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=76124&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=76124&r=support
Expected behavior: https://bugs.php.net/fix.php?id=76124&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=76124&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=76124&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=76124&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=76124&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=76124&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=76124&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=76124&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=76124&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=76124&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=76124&r=mysqlcfg