Re: [RFC PATCH 00/10] range-diff: fix segfault due to integer overflow

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi Ævar,

On Wed, 22 Dec 2021, Ævar Arnfjörð Bjarmason wrote:

> On Tue, Dec 21 2021, Philip Oakley wrote:
>
> > I fully agree that the range-diff should probably have a patch limit at
> > some sensible value.
>
> Why would it? If I'm willing to spend the CPU to produce a range-diff of
> an absurdly large range and I've got the memory why shouldn't we support
> it?
>
> We don't in cases like xdiff where it's not trivial to just raise the
> limits, but here it seems relatively easy.

To raise the limits you would have to understand the purpose of the
calculations so that you can understand the range their data type needs to
handle. The weights of the Hungarian Algorithm are distinctly _not_
pointers, therefore using `size_t` is most likely the wrong thing to do.

Of course you can glance over the details and try to avoid digging into
the algorithm to understand what it does before changing the data types
and introducing `st_mult()`-like functions and macros, but that only makes
it "relatively easy", at the price of "maybe incorrect". That would be in
line with what I unfortunately have had to come to expect of your patches.

The _actual_ "relatively easy" way is to imitate the limits we use in
xdiff (for similar reasons). As I said before.

Ciao,
Johannes