magic-string

Fixes #319. When normalizing negative indices in , , , and , indices below previously looped with , causing multiple wraps around the string and resolving to arbitrary in-bounds positions instead of matching semantics. Changes Replaced with across index resolution paths. Added tests verifying behavior when indices are less than .

The bug collected matches by driving in a loop: A zero-length match does not move , so the loop rematches at the same index forever. Any global regexp that can match the empty string hangs and then runs the process out of memory: , , , , and are all affected, so commenting out every line — a fairly ordinary thing to reach for — cannot be done today. The same loop never reset , so a regexp that has already been used resumes from wherever it stopped and silently skips earlier matches, where always starts from the beginning of the string: The fix is used instead. It steps over an empty match, and it does so by a whole code point when the regexp is unicode-aware, which a hand-rolled would get wrong for astral characters. is reset first, since starts from the regexp's own . That leaves the empty match reaching , which rejects a zero-length range. An empty match spans no characters, so there is no range to overwrite — the substitution is an insertion at the matched position, which is exactly what does with one. It is applied with , so it belongs to the range starting at that index, the same way an overwrite does. The string overloads had the same gap and are fixed alongside: threw, and could not terminate because clamps its start index to the string length and so never reports . Every case below now agrees with the built-in method: Notes README documents only two differences from , and neither covers empty matches, so this brings the code in line with what is already documented. The one behaviour worth stating — that a zero-length match inserts — is added there. The change is additive. I diffed 2406 combinations of source string, string and regexp pattern, string and function substitution, / and against : zero differences outside the empty-match cases above, which previously hung or threw. The existing 252 tests pass unchanged; 7 tests are added. , and both projects are clean. vs for the insertion is the one judgement call here. It is invisible unless something else is inserted at the same index, and keeps the replacement part of the range it replaced, the way does. Happy to switch it if you would rather it went the other way. Closes #336.

Version / @ 1bb4cce What happens collects matches by driving in a loop: A zero-length match does not advance , so the loop rematches at the same index forever. Any global regexp that can match the empty string never terminates — it allocates matches until the process runs out of memory: , , , , and are all affected, so prefixing or suffixing every line cannot be done through today. handles all of them: Second, smaller problem in the same loop is never reset before the scan, so a global regexp that has already been used resumes from wherever it stopped and silently skips earlier matches. always starts from the beginning of the string: Nothing is thrown here, the wrong characters are simply left alone. Non-global and string overloads Once the loop terminates, an empty match reaches , which rejects a zero-length range, so the non-global path throws rather than hangs: The string overloads have the same gap. throws as above, and cannot terminate either, for a different reason — clamps its start index to the string length, so on a 3-character string returns rather than and the loop never ends: Expected An empty match spans no characters, so there is no range to overwrite — the substitution is an insertion at the matched position, which is what does with one. The README lists only two differences from ("always match against the original string", "mutates the magic string state") and empty matches are not among them. So: terminate, start global regexps from the beginning of the string, and insert at a zero-length match. I have a PR ready for this.