Opened 14 years ago
Closed 14 years ago
#2157 closed Bugs (fixed)
Xpressive end-of-line match broken
Reported by: | Owned by: | Eric Niebler | |
---|---|---|---|
Milestone: | Boost 1.36.0 | Component: | xpressive |
Version: | Boost 1.35.0 | Severity: | Problem |
Keywords: | Cc: |
Description
End of line matching inside a string is broken, simple example:
Subject: abc\ndef\nghi Regex: .+$
I'm looking for "abc". The following xpressive-based code has odd results:
string text(argv[1]); sregex rex = sregex::compile(text, regex_constants::not_dot_newline);
smatch match; string subject("abc\ndef\nghi"); if (regex_search(subject.begin(), subject.end(), match, rex, regex_constants::match_default)) {
std::cout << "Match at: " << match.position(0) << " length: " << match.length(0);
}
.+$: Match at: 8 length: 3 $: Match at: 4 length: 0 .$: Match at: 10 length: 1
These definitely aren't right, it appears that the only place where end-of-line is matching is at end-of-string. Things get even stranger if I try to use Windows or Mac style end-of-line styles. If I use boost::regex instead then I get these results:
.+$: Match at: 0 length: 3 $: Match at: 3 length: 0 .$: Match at: 2 length: 1
These are the results I'd expect. It appears in Xpressive that the check in assert_line_base::is_line_break is broken, the following line:
if(traits_cast<Traits>(state).isctype(ch, this->newline_))
checks the previous character to see if it's a line break. I believe this should check the current character:
if(traits_cast<Traits>(state).isctype(*state.cur_, this->newline_))
This then gets me sane results:
.+$: Match at: 0 length: 3 $: Match at: 3 length: 0 .$: Match at: 2 length: 1
[note: Eric says that this patch is probably not correct as it causes regression failures]
Change History (3)
comment:1 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
The fix is not quite right ...
comment:3 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(In [47899]) fixed buggy eol matching behavior (fixes #2157)