From: Patrick Steinhardt <ps@pks.im>
To: Han-Wen Nienhuys <hanwenn@gmail.com>
Cc: "René Scharfe" <l.s.r@web.de>, "Git List" <git@vger.kernel.org>,
nasamuffin@google.com
Subject: Re: [PATCH] reftable: use xmalloc() and xrealloc()
Date: Tue, 9 Apr 2024 05:24:03 +0200 [thread overview]
Message-ID: <ZhS000b12DNoQ2pw@tanuki> (raw)
In-Reply-To: <CAOw_e7Z9dGeVU399D6o37L3am0abnYUrZnNQEFKhyUv=A2=j8g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]
On Mon, Apr 08, 2024 at 07:50:47PM +0200, Han-Wen Nienhuys wrote:
> Op ma 8 apr 2024 07:44 schreef Patrick Steinhardt <ps@pks.im>:
> >
> > It does raise the question what to do about the generic fallbacks. We
> > could start calling `abort()` when we observe allocation failures. It's
> > not exactly nice behaviour in a library though, where the caller may in
> > fact want to handle this case. But it may at least be better than
> > failing on a `NULL` pointer exception somewhere down the road. So it
> > might be the best alternative for now. We could then conver the reftable
> > library over time to handle allocation failures and, once that's done,
> > we can eventually drop such a call to `abort()`.
>
>
> I must admit that I didn't think this part through very much; I
> believe someone told me that libgit2 has pluggable memory allocation
> routines, so I tried to make the malloc pluggable here too.
That was me probably back when I was writing the libgit2 backend.
> Handling OOM better for the malloc calls themselves doesn't seem too
> difficult,
>
> hanwen@fedora:~/vc/git/reftable$ grep [cme]alloc *c | wc
> 57 276 3469
>
> However, it is probably pointless as long as strbuf_* functions do not
> signal OOM gracefully. There was some talk of libifying strbuf. Did
> that work include returning OOM error codes in case malloc returns
> null? A quick look at strbuf.h suggests not.
Yeah, `strbuf` also crossed my mind. And there are some other systems
that the reftable library calls into, like the tempfiles framework, that
would continue to use `xmalloc()` and related functions.
> I would just call xmalloc as default, rather than calling
> reftable_set_alloc, because it might be tricky to ensure it is called
> early enough.
I don't think it should be particularly tricky to call
`reftable_set_alloc()` early enough. The reftable code won't do any
allocations before we set up the refdb. So calling this in our `main()`
function in "common-main.c" should be sufficient.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-04-09 3:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-06 20:37 [PATCH] reftable: use xmalloc() and xrealloc() René Scharfe
2024-04-08 5:44 ` Patrick Steinhardt
2024-04-08 15:42 ` Junio C Hamano
2024-04-08 16:33 ` Patrick Steinhardt
2024-04-08 17:50 ` Han-Wen Nienhuys
2024-04-08 20:36 ` Junio C Hamano
2024-04-09 3:24 ` Patrick Steinhardt [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=ZhS000b12DNoQ2pw@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=hanwenn@gmail.com \
--cc=l.s.r@web.de \
--cc=nasamuffin@google.com \
/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.