From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] diff --no-index: unleak paths[] elements
Date: Wed, 07 Sep 2022 14:31:25 +0200 [thread overview]
Message-ID: <220907.86mtbbl5ua.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <36q9s463-rno9-9rs1-7qsq-5oqq23o30o0r@tzk.qr>
On Wed, Sep 07 2022, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Mon, 5 Sep 2022, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Sep 05 2022, Johannes Schindelin wrote:
>>
>> [...]
>> > + string_list_clear(&to_release, 1);
>> [...]
>>
>> * The free_util=1 in your code isn't needed/is a bug, we make no use of
>> "util" here, so it should be free_util=0
>
> Calling it a bug is a bit strong[...]
Yes, FWIW I meant that in the sense of "the author probably didn't mean
this" or "it was copy/pasted", but it has no effect currently, as we'll
always have NULL "util" members.
> , and misses the reason why I did it: future-proofing.
I didn't think it was intentional, but obviously you know better about
the intent.
"Future proofing" seems like a bad reason for that API use however. If
you look at the various "util" users some of them want to free() it, and
some don't. If you forget to free() the worst you'll have is a memory
leak, but if you have some boilerplate free() there you'll probably get
a segfault.
Without knowing what the future code looks like we don't know whether it
would make any sense to free() that util use.
> In any case, René took up Junio's ask and provided a new iteration that
> side-steps this concern altogether, therefore the point is now moot.
Indeed, that patch LGTM.
prev parent reply other threads:[~2022-09-07 12:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-02 21:27 [PATCH] unleak paths allocated in "diff --no-index" Junio C Hamano
2022-09-02 23:49 ` [PATCH v2] diff --no-index: unleak paths[] elements Junio C Hamano
2022-09-03 6:00 ` René Scharfe
2022-09-05 20:26 ` Junio C Hamano
2022-09-06 12:31 ` [PATCH 1/2] diff-no-index: release strbuf on queue error René Scharfe
2022-09-07 6:01 ` René Scharfe
2022-09-06 12:31 ` [PATCH 2/2] diff-no-index: release prefixed filenames René Scharfe
2022-09-07 10:03 ` Johannes Schindelin
2022-09-07 11:19 ` René Scharfe
2022-09-07 11:36 ` [PATCH v2 1/2] diff-no-index: release strbuf on queue error René Scharfe
2022-09-07 11:37 ` [PATCH v2 2/2] diff-no-index: release prefixed filenames René Scharfe
2022-09-07 11:45 ` [PATCH v2 3/2] diff-no-index: simplify argv index calculation René Scharfe
2022-09-07 19:37 ` Junio C Hamano
2022-09-05 10:03 ` [PATCH v2] diff --no-index: unleak paths[] elements Johannes Schindelin
2022-09-05 11:01 ` Ævar Arnfjörð Bjarmason
2022-09-07 10:06 ` Johannes Schindelin
2022-09-07 12:31 ` Ævar Arnfjörð Bjarmason [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=220907.86mtbbl5ua.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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).