Fix GH-14807 ext/standard levenshtein overflow on 3rd, 4th and 5th arguments.

[devnexen]

No description provided.

[nielsdos]

This doesn't solve the problem in general, also the weights are allowed to be negative

[devnexen]

Oh I see you already work on it he might be better if you continue with it :)

[nielsdos]

I didn't really come up with a general solution, see #13823 (comment)

[nielsdos]

@devnexen I thought about this more.

I think there's two ways to go about this:

1. Check beforehand if overflow can happen. If we set a number L to the largest cost (i.e. MAX(cost_ins, cost_rep, cost_del)) then overflow can only happen if MAX(ZSTR_LEN(string1), ZSTR_LEN(string2)) * L overflows, i.e. if L > ZEND_LONG_MAX / MAX(ZSTR_LEN(string1), ZSTR_LEN(string2)). And same reasoning for the lowest cost. If we check both of these cases, then we could throw beforehand. The disadvantage is that this can be overly defensive, e.g. using a PHP_INT_MAX weight to disallow one of the 3 operations is a legitimate trick and that would break even though the overflow will never happen in practice.
2. Use overflow-checked math in the computation of the distance. This is a bit harder / more annoying. It should be cheap for the CPU as the overflow flag is computed anyway when performing arithmetic. The advantage is that the function only throws when there actually is overflow, although then if you use extreme weights then depending on some input strings you get an exception and user code may not be prepared to deal with this. Then again, overflow should be rare.

[devnexen]

Thanks I ll look at it within the next days.

[cmb69]

I think there's two ways to go about this:

Both appear to be well-thought out and analyzed, and unfortunately neither seems to be fully backward compatible. I consider the current weighted levenshtein() functionality rather half-baked anyway; originally, the function signature supported callbacks (but not even general callables) for the costs, but since that was never implemented, it had been removed. If callables were properly supported, the function might be way more useful (albeit supposedly even much slower), but as is I still see not much use for this function, so it might indeed be "best" to just document the issue and let users deal with it. More elaborate support for levenshtein (and maybe other edit distance algorithms) could still be offered as PECL package (maybe something like this already exists). These are just my 2cents, though.