Re: [PATCH] strbuf.c: optimize program logic

[Jeff King <peff@peff.net>]

On Fri, Jan 29, 2021 at 02:09:12PM +0800, 胡哲宁 wrote:

> > I'm not sure that strbuf_grow() is safe, though. It relies on
> > ALLOC_GROW, which does not use st_add(), etc.
> >
> I want to say is that `strbuf_grow()` have checked overflow before
>  `ALLOC_GROW`,so that `strbuf_grow()`is maybe also safe too? :)
> void strbuf_grow(struct strbuf *sb, size_t extra)
> {
>        int new_buf = !sb->alloc;
>        if (unsigned_add_overflows(extra, 1) ||
>            unsigned_add_overflows(sb->len, extra + 1))
>                die("you want to use way too much memory");
>        ...

Oh, you're right. I misread it as checking only "extra", but of course
the second line there is making sure our total requested size does not
overflow.

I do think ALLOC_GROW() could still overflow internally as it sizes
larger than sb->len + extra. But this is quite unlikely on a 64-bit
system, as it would imply we're using on the order of 2^63 bytes of RAM
before we enter the function. It potentially could be a problem on a
32-bit system, though I'm not sure how much in practice (the numbers are
small enough to be reasonable, but I'm not sure it's realistic that a
single strbuf could already be using half of the available address
space).

-Peff