git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>, Han-Wen Nienhuys <hanwenn@gmail.com>
Subject: Re: [PATCH] reftable: use xmalloc() and xrealloc()
Date: Mon, 8 Apr 2024 07:44:46 +0200	[thread overview]
Message-ID: <ZhOETox9FTIOAShN@tanuki> (raw)
In-Reply-To: <963961ee-0f1d-42b8-8dda-5838e7a2ed94@web.de>

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

On Sat, Apr 06, 2024 at 10:37:55PM +0200, René Scharfe wrote:
> malloc(3) and realloc(3) can fail and return NULL.  None of the reftable
> code checks for that possibility and would happily dereference NULL
> pointers.  Use xmalloc() and xrealloc() instead like in the rest of Git
> to report allocation errors and exit cleanly, and to also honor the
> environment variable GIT_ALLOC_LIMIT.
> 
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
>  reftable/publicbasics.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/reftable/publicbasics.c b/reftable/publicbasics.c
> index 44b84a125e..f33a65df34 100644
> --- a/reftable/publicbasics.c
> +++ b/reftable/publicbasics.c
> @@ -19,14 +19,14 @@ void *reftable_malloc(size_t sz)
>  {
>  	if (reftable_malloc_ptr)
>  		return (*reftable_malloc_ptr)(sz);
> -	return malloc(sz);
> +	return xmalloc(sz);
>  }
> 
>  void *reftable_realloc(void *p, size_t sz)
>  {
>  	if (reftable_realloc_ptr)
>  		return (*reftable_realloc_ptr)(p, sz);
> -	return realloc(p, sz);
> +	return xrealloc(p, sz);
>  }
> 
>  void reftable_free(void *p)

These are part of the library interfaces that should ideally not be tied
to the Git code base at all so that they can theoretically be reused by
another project like libgit2. So I think that instead of rewriting the
generic fallbacks we should call `reftable_set_alloc()` somewhen early
in Git's startup code.

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()`.

Cc'ing Han-Wen's new mail address as he no longer works at Google.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-04-08  5:44 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 [this message]
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

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=ZhOETox9FTIOAShN@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=hanwenn@gmail.com \
    --cc=l.s.r@web.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).