From: Brandon Williams <bmwill@google.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] Document the string_list structure
Date: Thu, 21 Sep 2017 10:52:57 -0700 [thread overview]
Message-ID: <20170921175257.GA72184@google.com> (raw)
In-Reply-To: <20170921124338.26626-3-hanwen@google.com>
On 09/21, Han-Wen Nienhuys wrote:
> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> ---
> string-list.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/string-list.h b/string-list.h
> index 29bfb7ae4..08b534166 100644
> --- a/string-list.h
> +++ b/string-list.h
> @@ -8,6 +8,12 @@ struct string_list_item {
>
> typedef int (*compare_strings_fn)(const char *, const char *);
>
> +/* A resizable array of strings. The strings are owned if
nit: the start of the comment block should be on its own line:
/*
* A resizable ...
> + * 'strdup_strings' is set. It can be used as a sorted array, and a
> + * custom comparison may be given in 'cmp'. The field 'items[i].util'
> + * may be used to implement an array of pairs. In that case, the
> + * caller is responsible for managing memory pointed to by 'util'.
> + */
The util field can be freed if 'free_util' is set when calling
string_list_clear() but yeah, in general the caller is managing that
memory especially if a complex free function is required (in the case of
allocating a struct with dynamically allocated fields to be stored in
the util feild).
Just pointing that out, and I'm happy with this and the previous patch.
> struct string_list {
> struct string_list_item *items;
> unsigned int nr, alloc;
> --
> 2.14.1.821.g8fa685d3b7-goog
>
--
Brandon Williams
prev parent reply other threads:[~2017-09-21 17:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 12:43 [PATCH 0/2] Two small comment fixes Han-Wen Nienhuys
2017-09-21 12:43 ` [PATCH 1/2] Fix typo in submodule.h Han-Wen Nienhuys
2017-09-21 12:43 ` [PATCH 2/2] Document the string_list structure Han-Wen Nienhuys
2017-09-21 16:24 ` Jeff King
2017-09-21 17:52 ` Brandon Williams [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=20170921175257.GA72184@google.com \
--to=bmwill@google.com \
--cc=git@vger.kernel.org \
--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 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).