Re: [PATCH] strbuf.c: optimize program logic
- From
Jeff King <peff@peff.net>
- Date
- Jan 30, 2021, 08:50 UTC
- Message-ID
- <YBUd504cLUJTLEQY@coredump.intra.peff.net>
- In-Reply-To
- <CAOLTT8RroMdaty-SwAfK3OSeuFA7PE6ZhPCL4vgrxFxNihdGbQ@mail.gmail.com>
On Fri, Jan 29, 2021 at 02:09:12PM +0800, 胡哲宁 wrote:
Show 12 quoted lines
> > 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