nitely / nim-regex

Pure Nim regex engine. Guarantees linear time matching
https://nitely.github.io/nim-regex/
MIT License
228 stars 21 forks source link

regression: ^ incorrect when start != 0 #64

Closed timotheecour closed 4 years ago

timotheecour commented 4 years ago

/cc @nitely I was having a weird error in some program until I traced it back to a regression in nim-regex:

when true: # D20200501T000945
  import pkg/regex
  proc main()=
    let src = """xabc"""
    let start = 1
    var m: RegexMatch
    let regx = "^abc$".re
    let ok = find(src, regx, m, start = start)
    doAssert ok
  main()

ff6ab82: works master (92ff73c0c3a63d70a7b870dd17e5cd0c23b77282) : fails

git bisect says it's 92ff73c0c3a63d70a7b870dd17e5cd0c23b77282

nitely commented 4 years ago

That's re and nre behaviour. The workaround is to use match(txt, re"abc", m, start=1), or to add openArray[char] support so you can pass toOpenArray(src, 1, src.len-1) and start=0.

timotheecour commented 4 years ago
nitely commented 4 years ago

then it seems like a bug that we should report in nim repo

Thank you. I think it's a bug too, but I was trying to convince myself it's a feature :P.

match(txt, re"abc", m, start=1) wouldn't work if my regex is "^abc" instead of "^abc$" though IIUC

Yeah. That's why I suggested toOpenArray.

Since no other regex library has re/nre behaviour, and no one has reported the previous behaviour to be wrong, I'll label this as a bug and fix it.

timotheecour commented 4 years ago

thanks for the fix! I've submitted https://github.com/nim-lang/Nim/issues/14284

timotheecour commented 4 years ago

@nitely so in light of https://github.com/nim-lang/Nim/issues/14284 should we re-open to match re/nre behavior? sorry I was wrong initially on this one, the start + preserving context argument (eg https://github.com/nim-lang/Nim/issues/14284#issuecomment-626562406 or https://github.com/nim-lang/Nim/issues/14284#issuecomment-626673562) is convincing

nitely commented 4 years ago

Yes, I'll revert the changes.