cl-ppcre-devel

Download

cl-ppcre-devel@common-lisp.net

March 2012

3 participants
2 discussions

[cl-ppcre-devel] possible bug with non-word boundaries and greedy matching
by Moshe Looks 28 Mar '12

28 Mar '12

I have an odd little regular expression \B.* that seems to generate inconsistent behavior between CL-PPCRE and other regular expression engines that I've tried it with. Using CL-PPCRE: CL-USER> (cl-ppcre::scan "\\B.*" "foo bar baz") NIL This matches in Perl, PPCRE, and RE2. Am I missing something, or should CL-PPCRE be matching this as well? Oddly enough, change * to + leads CL-PPCRE to match: CL-USER> (cl-ppcre::scan "\\B.+" "foo bar baz") 1 11 #() #() It seems like + matching implies that * should as well... Thanks, Moshe

1 0

[cl-ppcre-devel] behavior of \w
by Robert Brown 12 Mar '12

12 Mar '12

Some folks I work with are using cl-ppcre. They've run into an incompatibility between cl-ppcre and the PCRE library that boils down to cl-ppcre's handling of \w. The behavior is documented in cl-ppcre's manual: CL-PPCRE uses ALPHANUMERICP to decide whether a character matches Perl's "\w", so depending on your CL implementation you might encounter differences between Perl and CL-PPCRE when matching non-ASCII characters. This reliance on ALPHANUMERICP may be a misfeature. It means that cl-ppcre behaves differently depending on the Lisp implementation it's running on. My co-workers desire compatibility between cl-ppcre on SBCL (where ALPHANUMERICP follows Unicode) and PCRE for matching Latin-1 encoded strings. They patched the cl-ppcre code to make \w match a-z, A-Z, 0-9, and underscore. Is there a better workaround for them? bob

2 2