bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'

[Stefan Kangas]

Mattias Engdegård <mattiase@acm.org> writes:

> It is basically your patch but slightly optimised; it turned out that
> the function call and allocation overhead of the original patch made
> it a tad too expensive (a pity, because it was very neat). Now
> performance is about the same as before when the pattern contains no
> submatches, and slightly above (< 10% slower) with one submatch. It
> seems worth the correctness.

Presumably this hasn't worked correctly for a long time, if ever.  Is
that correct?

I personally worry about the performance here.  Since we use regexps
heavily all over, it is not clear (to me) that 10 % overall performance
drop with subexpressions is worth it to work correctly in these rare
edge-cases.  I suppose we do have to fix the bug here, but is it
feasible to solve this in a way that has less performance impact?