From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/3] Documentation: document difference between release and free
Date: Wed, 24 Jul 2024 15:11:45 +0200 [thread overview]
Message-ID: <ZqD9keTtimiqJnJP@tanuki> (raw)
In-Reply-To: <CAOLa=ZScBn+sMB7BWMpsS=Ld0sUW14Li5JVuKPGKtY91hVo4jA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
On Wed, Jul 24, 2024 at 04:46:20AM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > We semi-regularly have discussions around whether a function shall be
> > named `release()` or `free()`. For most of the part we use these two
> > terminologies quite consistently though:
> >
>
> I noticed there is also `clear()` used in some places. Should we also
> mention that we don't recommend using `clear()` WRT freeing memory?
In any case I think we should decide on eithe using `clear()` or using
`release()` for consistency's sake. Which of both we use I don't quite
care, but the following very shoddy analysis clearly favors `release()`:
$ git grep '_clear(' | wc -l
844
$ git grep '_release(' | wc -l
2126
So yeah, I'm happy to explicitly mention that `clear()` shouldn't be
used in favor of `release()`.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-24 13:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 11:05 [PATCH 0/3] Documentation: some coding guideline updates Patrick Steinhardt
2024-07-24 11:05 ` [PATCH 1/3] Documentation: clarify indentation style for C preprocessor directives Patrick Steinhardt
2024-07-24 16:41 ` Junio C Hamano
2024-07-25 5:06 ` Junio C Hamano
2024-07-30 6:32 ` Patrick Steinhardt
2024-07-24 11:05 ` [PATCH 2/3] Documentation: document naming schema for struct-related functions Patrick Steinhardt
2024-07-24 11:42 ` Karthik Nayak
2024-07-24 13:12 ` Patrick Steinhardt
2024-07-24 16:50 ` Junio C Hamano
2024-07-24 16:56 ` Junio C Hamano
2024-07-30 6:41 ` Patrick Steinhardt
2024-07-24 11:05 ` [PATCH 3/3] Documentation: document difference between release and free Patrick Steinhardt
2024-07-24 11:46 ` Karthik Nayak
2024-07-24 13:11 ` Patrick Steinhardt [this message]
2024-07-24 14:30 ` Phillip Wood
2024-07-24 18:02 ` Junio C Hamano
2024-07-30 6:49 ` Patrick Steinhardt
2024-07-24 16:52 ` Junio C Hamano
2024-07-30 6:43 ` Patrick Steinhardt
2024-07-24 11:47 ` [PATCH 0/3] Documentation: some coding guideline updates Karthik Nayak
2024-07-30 7:24 ` [PATCH v2 0/5] " Patrick Steinhardt
2024-07-30 7:24 ` [PATCH v2 1/5] clang-format: fix indentation width for preprocessor directives Patrick Steinhardt
2024-07-30 14:19 ` Karthik Nayak
2024-07-30 7:24 ` [PATCH v2 2/5] Documentation: clarify indentation style for C " Patrick Steinhardt
2024-07-30 7:24 ` [PATCH v2 3/5] Documentation: document naming schema for structs and their functions Patrick Steinhardt
2024-07-30 7:24 ` [PATCH v2 4/5] Documentation: document idiomatic function names Patrick Steinhardt
2024-07-30 7:24 ` [PATCH v2 5/5] Documentation: consistently use spaces inside initializers Patrick Steinhardt
2024-07-30 20:55 ` [PATCH v2 0/5] Documentation: some coding guideline updates Junio C Hamano
2024-07-31 9:12 ` Karthik Nayak
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=ZqD9keTtimiqJnJP@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.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.