From: Phillip Wood <phillip.wood123@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: phillip.wood@dunelm.org.uk, git@vger.kernel.org,
"Jeff King" <peff@peff.net>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Elijah Newren" <newren@gmail.com>, "Eric Wong" <e@80x24.org>
Subject: Re: To "const char *" and cast on free(), or "char *" and no cast...
Date: Fri, 15 Oct 2021 11:03:24 +0100 [thread overview]
Message-ID: <5868076d-69cf-9b77-fa5c-5bb229333bd9@gmail.com> (raw)
In-Reply-To: <xmqqlf2vbbl8.fsf@gitster.g>
Hi Junio
On 14/10/2021 21:22, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> It's great to see these leaks being fixed. I wonder though if it would
>>> be better to change the structure definition so that 'name' and 'path'
>>> are no longer 'const'. That would be a better reflection of the new
>>> regime.[...]
>>
>> I think this is the right thing to do, but I'm not quite sure. There was
>> a thread at it here:
>>
>> https://lore.kernel.org/git/YUZG0D5ayEWd7MLP@carlos-mbp.lan/
>>
>> Where I chimed in and suggested exactly what you're saying here, but the
>> consensus seemed to go the other way, and if you grep:
>>
>> git grep -F 'free((char *)'
>>
>> You can see that we use this pattern pretty widely.
>
> Unfortunately, we probably need to make a trade-off and cannot eat
> the cake and have it at the same time.
>
> If we leave the .members non-const, the destructor may have to cast
> the constness away. If it is marked const * const, then we also
> need to let the constructor do the same.
It's not just in the destructor though, there are several other places
where we cast the value to free it suggesting it is not actually const.
I'd rather pass a "const struct branch_info*" around to all the callers
that are not mutating the struct (we already do that in some places but
not all) and change the structure definition to avoid the casts where it
is mutated.
> By marking the .members const, we can be sure that the users of the
> API will not muck with the values once the structure is instanciated
> and given to them, but the destructor need to cast the constness
> away. It may be lessor of two evils, as the need to cast is isolated
> in the _implementation_ of the API, and casts in the _users_ of the API
> would stand out more.
If it was just the destructor that was free()'ing the values I'd agree
but the struct gets mutated in other places as well.
Best Wishes
Phillip
next prev parent reply other threads:[~2021-10-15 10:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 0:10 [PATCH] checkout: fix "branch info" memory leaks Ævar Arnfjörð Bjarmason
2021-10-14 9:36 ` Phillip Wood
2021-10-14 19:54 ` To "const char *" and cast on free(), or "char *" and no cast Ævar Arnfjörð Bjarmason
2021-10-14 20:22 ` Junio C Hamano
2021-10-15 10:03 ` Phillip Wood [this message]
2021-10-15 16:00 ` Junio C Hamano
2021-10-14 23:36 ` Eric Wong
2021-10-15 9:50 ` Phillip Wood
2021-10-21 20:16 ` [PATCH v2] checkout: fix "branch info" memory leaks Ævar Arnfjörð Bjarmason
2021-10-24 18:30 ` Phillip Wood
2021-11-03 11:36 ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2021-11-16 18:27 ` [PATCH v4] " Ævar Arnfjörð Bjarmason
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5868076d-69cf-9b77-fa5c-5bb229333bd9@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=avarab@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).