On Mon, 11 May 2009, ND wrote:
> PCRE-PARTIAL says:
> "Because of the way certain internal optimizations are implemented in
> the pcre_exec() function, the PCRE_PARTIAL option cannot be used with
> all patterns."
>
> Restricted patterns are very uncomfortable. More: i think there is no
> way to automatically convert hundreds of existing non-restricted
> patterns to restricted ones.
I have been doing some work on partial matching, and I have now removed
all restrictions for partial matching with pcre_exec().
On Wed, 27 May 2009, ND wrote:
> Subject string: --z
> Regexp: z(*F)
> Why PCRE_ERROR_PARTIAL, not PCRE_ERROR_NOMATCH happens?
I have been able to change this to a more expected behaviour.
> > On Sun, 24 May 2009, ND wrote:
> >
> >> What do you think about adding following PCRE behavior:
> >>
> >> The return code PCRE_ERROR_MULTISEGMENT raised, and matching abandons
> >> immediately if at any time during the matching process PCRE needs to
> >> check (not bumpalong) the next symbol of subject string, but discovers
> >> an end of string. An extra parameter - last_bumpalong_offset - is
> >> returned.
I have implemented a new option called PCRE_PARTIAL_HARD, which has this
behaviour, except that it returns PCRE_ERROR_PARTIAL because I did not
see the need to have a different return code. (I have also renamed
PCRE_PARTIAL as PCRE_PARTIAL_SOFT, but kept the old name as a synonym
for compatibility.)
All this work has now been committed to the subversion code repository,
with updated documentation. It will be in the next release of PCRE, but
that will not be coming out for some weeks, because there are some other
issues that I still need to look at. However, if you want to experiment
with the new code, you can check out a copy of the development code
using this command:
svn co svn://vcs.exim.org/pcre/code/trunk pcre
Philip
--
Philip Hazel
