[cl-ppcre-devel] scan/property behavior?

Edi Weitz edi at agharta.de
Sun Apr 8 11:42:55 UTC 2012


Yep, that seems to be a bug.  I looked into it for a couple of minutes
and I /think/ the patch below fixes it, but it's been a long time
since I've looked into the ugly parts of CL-PPCRE, so take this with a
grain of salt.

Cheers,
Edi.


--- convert.lisp        (revision 4677)
+++ convert.lisp        (working copy)
@@ -701,11 +701,15 @@
 (defmethod convert-compound-parse-tree ((token (eql :property))
parse-tree &key)
   "The case for \(:PROPERTY <name>) where <name> is a string."
   (declare #.*standard-optimize-settings*)
+  (declare (special accumulate-start-p))
+  (setq accumulate-start-p nil)
   (make-instance 'char-class :test-function (resolve-property (second
parse-tree))))

 (defmethod convert-compound-parse-tree ((token (eql
:inverted-property)) parse-tree &key)
   "The case for \(:INVERTED-PROPERTY <name>) where <name> is a string."
   (declare #.*standard-optimize-settings*)
+  (declare (special accumulate-start-p))
+  (setq accumulate-start-p nil)
   (make-instance 'char-class :test-function (complement*
(resolve-property (second parse-tree)))))

 (defmethod convert-compound-parse-tree ((token (eql :flags)) parse-tree &key)

On Sun, Apr 8, 2012 at 4:04 AM, Cyrus Harmon <ch-lisp at bobobeach.com> wrote:
>
> I was noticing some strange behavior with cxml-rng and David Lichteblau pointed out that the problem might be due to cl-ppcre and provided this example:
>
> (let ((regex1 '(:SEQUENCE :start-anchor
>                (:greedy-repetition 0 42 (:property digit-char-p))
>                #\-))
>      (regex2 '(:SEQUENCE :start-anchor
>                (:property digit-char-p)
>                #\-))
>      (str "8-"))
>  (values (multiple-value-list (ppcre:scan regex1 str))
>          (multiple-value-list (ppcre:scan regex2 str))))
>
>
> Regex1 works as expected (it matches 8-) but the second one doesn't. It's possible I don't understand (well more than possible) how :property works, but I would have expected either both or neither of these to fail. Could this be due to a bug in cl-ppcre?
>
> thanks,
>
> Cyrus
>
>
> _______________________________________________
> cl-ppcre-devel site list
> cl-ppcre-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel
>




More information about the Cl-ppcre-devel mailing list