Sorry, I had not thought about that. I just checked with the example given in the bug report and it's effectively slower (~25% on this expression).
On Thursday 07 August 2008 14:35:12 Nuno Lopes wrote: > No! > Last time I benchmark it, it has about 100x slower, so I don't think so.. > If you need to match large amounts of data, just increase the stack size. > ulimit is your friend :) > > Nuno > > > ----- Original Message ----- > From: "Arnaud Le Blanc" <[EMAIL PROTECTED]> > To: <internals@lists.php.net> > Sent: Thursday, August 07, 2008 1:24 PM > Subject: [PHP-DEV] PCRE and recursion: NO_RECURSE flag > > > Hi, > > > > PCRE can be highly recursive [1] and this can cause segmentation faults > > [2]. > > This is a known problem and the pcre ini settings avoids the segfaults, > > but > > the execution of the expression will fail anyway. > > > > PCRE has a NO_RECURSE flag which makes the match() internal function no > > recursive and avoids this problem. The configure switch for this option > > is -- > > disable-stack-for-recursion. NO_RECURSE is documented in pcre_exec.c. > > > > This can be easily enabled [3] for the bundled PCRE. It seems to be safe > > to > > enable that. Actually the PCRE test suite pass with NO_RECURSE enabled, > > and > > segfaults without. Can this be enabled ? > > > > [1] http://manpages.courier-mta.org/htmlman3/pcrestack.3.html > > [2] http://bugs.php.net/bug.php?id=45735 > > [3] http://arnaud.lb.s3.amazonaws.com/pcre_no_recurse.patch > > > > Regards, > > > > Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
