On Sun, 9 Apr 2006, Nuno Lopes wrote:
OK, I've made a patch for you:
http://mega.ist.utl.pt/~ncpl/php_pcre_match_limit.txt
adds: pcre.match_limit and pcre.match_limit_recursion.
BTW, I think we should print a warning when pcre_exec() fails. Currently
we
just fail silently.
We should only do that is the regexp is the *only* parameter that can
make pcre_exec fail. If the subject string can influence this we should
not show a warning as you'd have to silence that by hand then.
Derick
I understand your point of view, but it might be usefull to have a way to
report/fetch the error.
For example, with this patch, pcre_exec() might return
PCRE_ERROR_MATCHLIMIT. How do you know that (to possibly increase the
recursion depth)? Now you don't!
Porbably all errors returned by pcre_exec() can be influenced by the subject
string. But I think that generating at least a E_NOTICE would be useful.
And take a look at return values we can possibly receive:
#define PCRE_ERROR_NULL (-2)
#define PCRE_ERROR_BADOPTION (-3)
#define PCRE_ERROR_BADMAGIC (-4)
#define PCRE_ERROR_UNKNOWN_NODE (-5)
#define PCRE_ERROR_NOMEMORY (-6)
#define PCRE_ERROR_NOSUBSTRING (-7)
#define PCRE_ERROR_MATCHLIMIT (-8)
#define PCRE_ERROR_CALLOUT (-9) /* Never used by PCRE itself */
#define PCRE_ERROR_BADUTF8 (-10)
#define PCRE_ERROR_BADUTF8_OFFSET (-11)
#define PCRE_ERROR_INTERNAL (-14)
#define PCRE_ERROR_BADCOUNT (-15)
#define PCRE_ERROR_RECURSIONLIMIT (-21)
None of them will be trigered by a "malicious" string (excluding the
BADUTF8, but then you should probably validate it). Most other errors are
caused by a bad usage of the PCRE's API, which isn't the case :)
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
