From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "René Scharfe" <l.s.r@web.de>, "Git List" <git@vger.kernel.org>,
"Junio C Hamano" <gitster@pobox.com>, "Eric Wong" <e@80x24.org>
Subject: Re: [PATCH] khash: clarify that allocations never fail
Date: Sat, 03 Jul 2021 13:35:45 +0200 [thread overview]
Message-ID: <87v95r8w86.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <YOA+IibZw6C9mkdF@coredump.intra.peff.net>
On Sat, Jul 03 2021, Jeff King wrote:
> On Sat, Jul 03, 2021 at 12:05:46PM +0200, René Scharfe wrote:
>
>> We use our standard allocation functions and macros (xcalloc,
>> ALLOC_ARRAY, REALLOC_ARRAY) in our version of khash.h. They terminate
>> the program on error, so code that's using them doesn't have to handle
>> allocation failures. Make this behavior explicit by replacing the code
>> that handles allocation errors in kh_resize_ and kh_put_ with BUG calls.
>
> Seems like a good idea.
>
> We're very sloppy about checking the "ret" field from kh_put_* for
> errors (it's a tri-state for "already existed", "newly added", or
> "error"). I think that's not a problem because as you show here, we
> can't actually hit the error case. This makes that much more obvious.
>
> Two nits if we wanted to go further:
>
>> diff --git a/khash.h b/khash.h
>> index 21c2095216..84ff7230b6 100644
>> --- a/khash.h
>> +++ b/khash.h
>> @@ -126,7 +126,7 @@ static const double __ac_HASH_UPPER = 0.77;
>> if (h->size >= (khint_t)(new_n_buckets * __ac_HASH_UPPER + 0.5)) j = 0; /* requested size is too small */ \
>> else { /* hash table size to be changed (shrink or expand); rehash */ \
>> ALLOC_ARRAY(new_flags, __ac_fsize(new_n_buckets)); \
>> - if (!new_flags) return -1; \
>> + if (!new_flags) BUG("ALLOC_ARRAY failed"); \
>
> I converted this in b32fa95fd8 (convert trivial cases to ALLOC_ARRAY,
> 2016-02-22), but left the now-obsolete error-check.
>
> But a few lines below...
>
>> memset(new_flags, 0xaa, __ac_fsize(new_n_buckets) * sizeof(khint32_t)); \
>> if (h->n_buckets < new_n_buckets) { /* expand */ \
>> REALLOC_ARRAY(h->keys, new_n_buckets); \
>
> These REALLOC_ARRAY() calls are in the same boat. You dropped the error
> check in 2756ca4347 (use REALLOC_ARRAY for changing the allocation size
> of arrays, 2014-09-16).
>
> Should we make the two match? I'd probably do so by making the former
> match the latter, and just drop the conditional and BUG entirely.
Yes, I don't see why we should be guarding theis anymore than we do
xmalloc() or other x*() functions in various places (which is what it
resolves to).
If anything we might consider renaming it via coccinelle to
XALLOC_ARRAY(), XREALLOC_ARRAY() etc. to make it clear that they handle
any errors themselves.
next prev parent reply other threads:[~2021-07-03 11:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 10:05 [PATCH] khash: clarify that allocations never fail René Scharfe
2021-07-03 10:38 ` Jeff King
2021-07-03 10:44 ` Jeff King
2021-07-03 11:35 ` Ævar Arnfjörð Bjarmason [this message]
2021-07-03 12:56 ` René Scharfe
2021-07-03 13:05 ` Ævar Arnfjörð Bjarmason
2021-07-04 9:01 ` Jeff King
2021-07-04 9:41 ` René Scharfe
2021-07-04 10:11 ` Jeff King
2021-07-03 12:57 ` René Scharfe
2021-07-03 12:57 ` [PATCH v2] " René Scharfe
2021-07-04 9:05 ` Jeff King
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=87v95r8w86.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--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.