Do the "maximum place \n can appear within the float range" calculation
in chars rather than bytes. Doing it in bytes is logically incorrect,
although I think the worst outcome is that a string is falsely accepted
by intuit then has to be failed by a full run of the regex engine.
But I couldn't think of a test that would show a significant performance
difference.
goto fail_finish;
}
+ /* since *t == '\n', it's safe to do +1 here rather than HOP(t,1) */
rx_origin = t + 1; /* earliest possible origin is after the \n */
- if (t >= check_at - prog->check_offset_min) {
+ if (prog->substrs->check_ix == 0 /* check is anchored */
+ || t >= HOP3c(check_at, - prog->check_offset_min, strpos))
+ {
/* Position contradicts check-string; either because
* check was anchored (and thus has no wiggle room),
* or check was float and t is above the float range */