git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] reftable: use xmalloc() and xrealloc()

From
Patrick Steinhardt <ps@pks.im>
Date
Apr 8, 2024, 05:44 UTC
Message-ID
<ZhOETox9FTIOAShN@tanuki>
In-Reply-To
<963961ee-0f1d-42b8-8dda-5838e7a2ed94@web.de>
On Sat, Apr 06, 2024 at 10:37:55PM +0200, René Scharfe wrote:
Show 32 quoted lines
> 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
Previous: René ScharfeNext: Junio C Hamano
Message 2 of 7 in “reftable: use xmalloc() and xrealloc()”
  1. reftable: use xmalloc() and xrealloc()René Scharfe, Apr 6, 2024
  2. Patrick SteinhardtApr 8, 2024
  3. Junio C HamanoApr 8, 2024
  4. Patrick SteinhardtApr 8, 2024
  5. Han-Wen NienhuysApr 8, 2024
  6. Junio C HamanoApr 8, 2024
  7. Patrick SteinhardtApr 9, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.