From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] commit: fix "author_ident" leak
Date: Wed, 18 May 2022 09:30:44 -0700 [thread overview]
Message-ID: <xmqqtu9mx0p7.fsf@gitster.g> (raw)
In-Reply-To: 220517.86fsl86z1s.gmgdl@evledraar.gmail.com
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> But even accounting for that, I don't see what the "more maintainable"
> here refers to. The approach I suggested would s/UNLEAK/strbuf_release/
> in the 4th hunk, but otherwise be equivalent.
Judicious use of UNLEAK() has documentation value to tell readers
which use of pointer variables need to be explicitly released, and
which pointer variables can just implicitly released by going out of
scope at the end. There are also a few other small added benefits
(they do not have to be changed when the helper needed to do the
real release changes, and not doing an explicit real release on
resources when there no need to is conceptually cleaner). But they
are icing on the cake.
Sorry for a late reply---I go offline every other Tuesday and
yesterday was such a Tuesday.
prev parent reply other threads:[~2022-05-18 16:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 8:21 [PATCH 0/2] commit: trivial leak fix, add 2 tests to linux-leaks CI Ævar Arnfjörð Bjarmason
2022-02-16 8:21 ` [PATCH 1/2] commit: fix "author_ident" leak Ævar Arnfjörð Bjarmason
2022-02-16 17:59 ` Junio C Hamano
2022-02-16 8:21 ` [PATCH 2/2] commit: use strbuf_release() instead of UNLEAK() Ævar Arnfjörð Bjarmason
2022-02-16 18:03 ` Junio C Hamano
2022-02-16 18:30 ` Junio C Hamano
2022-02-18 12:35 ` Whether to keep using UNLEAK() in built-ins (was: [PATCH 2/2] commit: use strbuf_release() instead of UNLEAK()) Ævar Arnfjörð Bjarmason
2022-02-18 18:19 ` Whether to keep using UNLEAK() in built-ins Junio C Hamano
2022-02-18 19:31 ` Ævar Arnfjörð Bjarmason
2022-05-12 22:51 ` [PATCH] commit: fix "author_ident" leak Junio C Hamano
2022-05-17 13:48 ` Ævar Arnfjörð Bjarmason
2022-05-18 16:30 ` Junio C Hamano [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=xmqqtu9mx0p7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
/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).