| Summary: | Incorrect reluctant matching when they contain another quantifiers | ||
|---|---|---|---|
| Product: | Regexp | Reporter: | Oleg Sukhodolsky <o_sukhodolsky> |
| Component: | Other | Assignee: | Jakarta Notifications Mailing List <notifications> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
I think I have another approach - fix processing of OP_RELUCTANTXXX, and implement OP_PLUS etc similarly to cut down on program length and complexity. Would you have more testcases? Specifically I'd like to have more complicated testcasees where plus/star/maybe are used several times and grouped/nested into each other. Thanks. implemented fix for reluctant closures |
I've tried to match 1__ line against ^(1_*)??_$, ^(1_*)*?_$, and ^(1_*)+?_$ In all cases I get negative answer. But ^(|1_*)_$ (which is the same as last one) matches the string. As far as I understand the cause of this problem is that we use OP_RELUCTANTXXX for these quantifiers and process them incorrectly. Perhaps we should do the same as for greedy quantifiers, i.e. replace X?? by (|X), X+? - XX*?, and X*? by (|X{gotoX})