All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	"Han-Wen Nienhuys" <hanwen@google.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: [RFC PATCH 0/2] reftable: remove poor man's SANITIZE=address, fix a memset() bug
Date: Fri, 15 Apr 2022 12:21:34 +0200	[thread overview]
Message-ID: <RFC-cover-0.2-00000000000-20220415T101740Z-avarab@gmail.com> (raw)
In-Reply-To: <20220415083058.29495-1-carenas@gmail.com>

On Fri, Apr 15 2022, Carlo Marcelo Arenas Belón wrote:

> 1214aa841bc (reftable: add blocksource, an abstraction for random
> access reads, 2021-10-07), makes the assumption that it is ok to
> free a reftable_block pointing to NULL if the size is also set to
> 0, but implements that using a memset call that at least in glibc
> based system will trigger a runtime exception if called with a
> NULL pointer as its first parameter.

FWIW I've been carrying 1/2 here for a while in my local tree,
i.e. reftable/* has various abstractions and indirections that aren't
really needed. In this case we can just get rid of that & free them,
so the memset()s you fixed can just be removed.

The 2/2 is then another memset() issue I spotted when looking at this
again, -fanalyzer notes the bug related to it.

Ævar Arnfjörð Bjarmason (2):
  reftable: remove the "return_block" abstraction
  reftable: don't memset() a NULL from failed malloc()

 reftable/block.c                |  4 +---
 reftable/blocksource.c          | 28 +---------------------------
 reftable/publicbasics.c         |  2 ++
 reftable/reftable-blocksource.h |  2 --
 4 files changed, 4 insertions(+), 32 deletions(-)

-- 
2.36.0.rc2.863.gfc2c14e3b91


  reply	other threads:[~2022-04-15 10:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-15  7:02 [PATCH] reftable: avoid undefined behaviour breaking t0032 Carlo Marcelo Arenas Belón
2022-04-15  7:10 ` Junio C Hamano
2022-04-15  8:30 ` [PATCH v2] " Carlo Marcelo Arenas Belón
2022-04-15 10:21   ` Ævar Arnfjörð Bjarmason [this message]
2022-04-15 10:21     ` [RFC PATCH 1/2] reftable: remove the "return_block" abstraction Ævar Arnfjörð Bjarmason
2022-04-15 13:37       ` René Scharfe
2022-04-25  9:57       ` Han-Wen Nienhuys
2022-04-25 17:30         ` Junio C Hamano
2022-04-15 10:21     ` [RFC PATCH 2/2] reftable: don't memset() a NULL from failed malloc() Ævar Arnfjörð Bjarmason
2022-04-15 13:37       ` René Scharfe
2022-04-15 13:53         ` Ævar Arnfjörð Bjarmason
2022-04-15 14:30           ` Phillip Wood
2022-04-15 15:20             ` Ævar Arnfjörð Bjarmason
2022-04-15 16:23               ` Junio C Hamano
2022-04-25 10:30                 ` Han-Wen Nienhuys
2022-04-25 10:18   ` [PATCH v2] reftable: avoid undefined behaviour breaking t0032 Han-Wen Nienhuys

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=RFC-cover-0.2-00000000000-20220415T101740Z-avarab@gmail.com \
    --to=avarab@gmail.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hanwen@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.