This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author glchapman
Recipients
Date 2003-04-20.12:33:09
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=86307

Gustavo, thanks for reworking and applying the patch.  And 
thanks for catching the bug in the MIN_REPEAT_ONE where I 
was not calling lastmark_restore in the right place; it does need 
to be inside the loop (though I think it could be at the bottom -- 
it's not necessary if SRE_COUNT returns 0).

I note in your checkin message you are concerned about 
whether all calls to SRE_MATCH need to be protected by 
LASTMATCH_SAVE/RESTORE.  These should only be 
necessary where SRE_MATCH returns 0 but nevertheless 
matching continues (i.e., a backtrack point or an alternative).  So 
they are clearly not necessary for ASSERT and REPEAT.  
ASSERT_NOT is an interesting case.  Right now, a capturing 
group (inside the negative assertion) which matches before the 
subpattern fails is reported as having matched; this is the way 
Perl works.  You could argue that it would be more consistent for 
these groups always to report as unmatched (Jeffrey Friedl 
implies as much in the first edition of his book), in which case 
the ASSERT_NOT should be surrounded by 
LASTMARK_SAVE/RESTORE.

Anyway, it should not be necessary to protect the first part of the 
MAX_UNTIL and MIN_UNTIL opcodes (the part which assures 
the repeat has matched the minimum number of times); if this 
part fails, it causes this invocation of SRE_MATCH to return 0.  I 
note that you have protected this part of MAX_UNTIL but not 
MIN_UNTIL.  We should probably be consistent here and remove 
the protection from MAX_UNTIL.
History
Date User Action Args
2007-08-23 15:21:50adminlinkissue712900 messages
2007-08-23 15:21:50admincreate