From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/7] oid_array cleanups
Date: Tue, 14 Apr 2020 18:35:46 -0600 [thread overview]
Message-ID: <20200415003546.GE7457@syl.local> (raw)
In-Reply-To: <20200330140247.GA476088@coredump.intra.peff.net>
Hi Peff,
On Mon, Mar 30, 2020 at 10:02:47AM -0400, Jeff King wrote:
> I recently encountered a repo in the wild that had over 2^31 objects,
> and found that cat-file barfed:
>
> $ git cat-file --batch-all-objects --batch-check
> fatal: size_t overflow: 32 * 18446744071562067968
>
> The issue is that we use an "int" to store the count and the allocation.
> Fortunately our st_mult() protection kicks in before we end up with an
> undersized buffer, so this shouldn't be dangerous. And while I'd argue
> that having that many objects is probably silly and likely to cause
> other problems, I'd just as soon we kept our allocating code as robust
> as possible.
>
> The first patch is the actual fix, followed by some related type
> cleanup. The rest of it is just leftovers from the
> s/sha1_array/oid_array/ transition a few years back.
>
> [1/7]: oid_array: use size_t for count and allocation
> [2/7]: oid_array: use size_t for iteration
> [3/7]: oid_array: rename source file from sha1-array
> [4/7]: test-tool: rename sha1-array to oid-array
> [5/7]: bisect: stop referring to sha1_array
> [6/7]: ref-filter: stop referring to "sha1 array"
> [7/7]: oidset: stop referring to sha1-array
Thanks for this. I reviewed the patch, which was a breeze thanks to how
you broke it out. I don't think that I said anything useful in my actual
review, which is to say that this looks good from my perspective.
Sorry that I let it sit in my inbox for a few days. Trying to get better
about that :).
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Thanks,
Taylor
prev parent reply other threads:[~2020-04-15 0:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 14:02 [PATCH 0/7] oid_array cleanups Jeff King
2020-03-30 14:03 ` [PATCH 1/7] oid_array: use size_t for count and allocation Jeff King
2020-03-30 14:09 ` Jeff King
2020-04-15 0:27 ` Taylor Blau
2020-03-30 14:03 ` [PATCH 2/7] oid_array: use size_t for iteration Jeff King
2020-03-30 14:03 ` [PATCH 3/7] oid_array: rename source file from sha1-array Jeff King
2020-04-15 0:34 ` Taylor Blau
2020-03-30 14:04 ` [PATCH 4/7] test-tool: rename sha1-array to oid-array Jeff King
2020-03-30 14:04 ` [PATCH 5/7] bisect: stop referring to sha1_array Jeff King
2020-03-30 14:04 ` [PATCH 6/7] ref-filter: stop referring to "sha1 array" Jeff King
2020-03-30 14:04 ` [PATCH 7/7] oidset: stop referring to sha1-array Jeff King
2020-04-15 0:35 ` Taylor Blau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200415003546.GE7457@syl.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.