cl-ppcre-devel March 2012

cl-ppcre-devel@common-lisp.net

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

cl-ppcre-devel March 2012