Repository navigation
SRE bugs with capturing groups in negative assertions #38345
Description
| BPO | 725149 |
|---|---|
| Nosy | @birkenfeld |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-02-07.20:50:26.991>
created_at = <Date 2003-04-21.18:22:00.000>
labels = ['expert-regex', 'build']
title = 'SRE bugs with capturing groups in negative assertions'
updated_at = <Date 2009-02-23.21:48:45.776>
user = 'https://bugs.python.org/glchapman'bugs.python.org fields:
activity = <Date 2009-02-23.21:48:45.776>
actor = 'georg.brandl'
assignee = 'niemeyer'
closed = True
closed_date = <Date 2008-02-07.20:50:26.991>
closer = 'draghuram'
components = ['Regular Expressions']
creation = <Date 2003-04-21.18:22:00.000>
creator = 'glchapman'
dependencies = []
files = ['852', '853', '13158']
hgrepos = []
issue_num = 725149
keywords = []
message_count = 7.0
messages = ['15565', '15566', '15567', '15568', '62179', '82636', '82644']
nosy_count = 5.0
nosy_names = ['georg.brandl', 'glchapman', 'niemeyer', 'draghuram', 'daniel_py']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue725149'
versions = ['Python 2.6']
Activity
glchapman commentedon Apr 21, 2003
SRE is broken in some subtle ways when you combine
capturing groups with assertions. For example:
In the above '(a)' has matched an empty string. Or
worse:
Here '(a)' matches 'b'.
Although Perl reports matches for groups in negative
assertions, I think it is better to adopt the PCRE rule
that these groups are always reported as unmatched
outside the assertion (inside the assertion, if used with
backreferences, they should behave as normal). This
would make the handling of subpatterns in negative
assertions consistent with that of subpatterns in
branches:
In the above, although '(a)' matches before the branch
fails, the failure of the branch means '(a)' is considered
not to have matched.
Anyway, the attached patch is an effort to fix this
problem by saving the values of marks before calling the
assertion, and then restoring them afterwards (thus
undoing whatever might have been done in the assertion).
glchapman commentedon Apr 22, 2003
Logged In: YES
user_id=86307
In thinking further, I realized that positive assertions are also
affected by the second problem. E.g.:
The problem here is that a successful match in an assertion
can leave marks at the top of the mark stack which then get
popped in the wrong place. Attaching a new patch which
should catch this problem for both kinds of assertions (and
which also should "unmark" groups in negative assertions).
niemeyer commentedon Apr 27, 2003
Logged In: YES
user_id=7887
Greg, I think there are two different issues here.
One of them is related to a wrong behavior from
mark_save/restore(), which don't restore the stackbase
before restoring the marks. Asserts were afected because
they're the only recursive ops that can continue the loop,
but the problem would happen to any operation with the same
behavior. So, rather than hardcoding this into asserts, I
have changed mark_save/restore() to always restore the
stackbase before restoring the marks. This should fix these
two cases you presented:
And was applied as:
Modules/_sre.c: 2.95
Lib/test/test_re.py: 1.41
The other issue is related to the asserts which are leaving
half-marked groups. While your solution does work, it
changes the current behavior, which is also compatible to
how perl works. I understand that individual groups matching
when the whole string doesn't match is atypical. OTOH, a
negative assertion *is* atypical, and IMO denying external
group access won't help the user to understand how it works.
In other words, I think it's better to have incomplete
support for the moment, than having none.
This way, we can think further about this, and look for an
elegant solution to fix that support, certainly including
some algorithm to check for half-marked groups.
Thank you very much for spotting these bugs, and submitting
a solution for them.
glchapman commentedon Apr 28, 2003
Logged In: YES
user_id=86307
Gustavo,
Just a quick note on compatibility. As I mentioned, the PCRE
rule is that groups in negative asserts do not match. So, with
Python 2.2, you get this result using pre:
Although I understand your argument, I'll just say that I
personally think it would be better to move toward compatibility
with pre (which after all was the official Python regex engine
before sre), rather than to remain partly compatible with Perl.
Thanks for reviewing my patches and fixing the bugs!
draghuram commentedon Feb 7, 2008
looks to have been fixed.
danielpy commentedon Feb 23, 2009
I need help to resolve this problem caused when program a scheduled task
whit CRONTAB, generated result:
[-]SRE bugs with capturing groups in negative assertions[/-][+]_sre.MAGIC[/+][-]SRE bugs with capturing groups in negative assertions[/-][+]_sre.MAGIC[/+]birkenfeld commentedon Feb 23, 2009
Please do not hijack existing issues. In the case of this problem, do
not open an issue at all, but ask in a Python mailing list or newsgroup.
[-]_sre.MAGIC[/-][+]SRE bugs with capturing groups in negative assertions[/+][-]_sre.MAGIC[/-][+]SRE bugs with capturing groups in negative assertions[/+]