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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 22, 2021, 20:50 UTC
Message-ID: <nycvar.QRO.7.76.6.2112222143080.347@tvgsbejvaqbjf.bet>
In-Reply-To: <211222.86r1a5plsm.gmgdl@evledraar.gmail.com>

Hi Ævar,

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

Show 11 quoted lines

> 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