What's your rationale for this fix? What sort of regression happened?

OK, so let me explain:
preg_replace($regex, $replace, $str, $limit);
Short answer: It was failling if $limit < $number_of_matches.

How this bug was introduced? This started with your commit 3 weeks ago that introduced the preg_last_error(). Later when Tony fixed a mem leak in the same place, the problem became even worst (although the commit was correct). Now looking at the bug report (http://bugs.php.net/37800), example #1. After your commit, it would return ''One ". After Tony's commit it returned NULL. The correct answer is "One 111111111"


The problematic code change:
@@ -1011,7 +1088,7 @@ PHPAPI char *php_pcre_replace(char *rege
   if (limit != -1)
    limit--;

-  } else { /* Failed to match */
+  } else if (count == PCRE_ERROR_NOMATCH) {
   /* If we previously set PCRE_NOTEMPTY after a null match,
      this is not necessarily the end. We need to advance
      the start offset, and continue. Fudge the offset values
@@ -1036,6 +1113,9 @@ PHPAPI char *php_pcre_replace(char *rege
    result[*result_len] = '\0';
    break;
   }
+  } else {
+   pcre_handle_exec_error(count TSRMLS_CC);
+   break;
  }


Previously it entered in the first else when limit == 0 (and when there was an error too, but thats another story). My fix just restores the old behaviour, that is enter in that piece of code.

I hope it is more clear now.
Nuno



On Jun 15, 2006, at 11:33 AM, Nuno Lopes wrote:

nlopess Thu Jun 15 15:33:25 2006 UTC

  Added files:                 (Branch: PHP_5_2)
    /php-src/ext/pcre/tests bug37800.phpt

  Modified files:
    /php-src/ext/pcre php_pcre.c
  Log:
  fix bug #37800: preg_replace() limit parameter odd behaviour
  #this is a regression in PHP_5_2 and HEAD branches only

http://cvs.php.net/viewcvs.cgi/php-src/ext/pcre/php_pcre.c? r1=1.168.2.9.2.5&r2=1.168.2.9.2.6&diff_format=u
Index: php-src/ext/pcre/php_pcre.c
diff -u php-src/ext/pcre/php_pcre.c:1.168.2.9.2.5 php-src/ext/pcre/ php_pcre.c:1.168.2.9.2.6
--- php-src/ext/pcre/php_pcre.c:1.168.2.9.2.5 Wed Jun 14 17:52:56 2006
+++ php-src/ext/pcre/php_pcre.c Thu Jun 15 15:33:25 2006
@@ -16,7 +16,7 @@

+--------------------------------------------------------------------- -+
  */

-/* $Id: php_pcre.c,v 1.168.2.9.2.5 2006/06/14 17:52:56 nlopess Exp  $ */
+/* $Id: php_pcre.c,v 1.168.2.9.2.6 2006/06/15 15:33:25 nlopess Exp  $ */

 #ifdef HAVE_CONFIG_H
 #include "config.h"
@@ -1091,7 +1091,7 @@
 if (limit != -1)
 limit--;

- } else if (count == PCRE_ERROR_NOMATCH) {
+ } else if (count == PCRE_ERROR_NOMATCH || limit == 0) {
 /* If we previously set PCRE_NOTEMPTY after a null match,
    this is not necessarily the end. We need to advance
    the start offset, and continue. Fudge the offset values

http://cvs.php.net/viewcvs.cgi/php-src/ext/pcre/tests/bug37800.phpt? view=markup&rev=1.1
Index: php-src/ext/pcre/tests/bug37800.phpt
+++ php-src/ext/pcre/tests/bug37800.phpt

--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to