All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] parse-options-cb.c: use string_list_append_nodup in OPT_STRING_LIST()
Date: Sun, 12 Jun 2016 18:03:16 -0400	[thread overview]
Message-ID: <20160612220316.GB5428@sigill.intra.peff.net> (raw)
In-Reply-To: <20160610115726.4805-1-pclouds@gmail.com>

On Fri, Jun 10, 2016 at 06:57:26PM +0700, Nguyễn Thái Ngọc Duy wrote:

> If the given string list has strdup_strings set (*), the string will be
> duplicated again. Pointless and leak memory. Ignore that flag.
> 
> (*) only interpret-trailers.c does it at the moment
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  parse-options-cb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/parse-options-cb.c b/parse-options-cb.c
> index 239898d..8a1b6e6 100644
> --- a/parse-options-cb.c
> +++ b/parse-options-cb.c
> @@ -144,7 +144,7 @@ int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
>  	if (!arg)
>  		return -1;
>  
> -	string_list_append(v, xstrdup(arg));
> +	string_list_append_nodup(v, xstrdup(arg));

Hmm. So I agree this is an improvement, in the sense that we are
double-allocating when v->strdup_strings is set.  But I think there's a
deeper issue here. Why are we always allocating in the first place?

If the memory we are getting in "arg" is not stable, then we _do_ need
to make a copy of it. But in that case, we want "strdup_strings" to be
set; without it any time we later run string_list_clear(), we leak the
allocated memory, because the struct has no idea that it is the owner of
the memory (and we do call string_list_clear() when we see "--no-foo").

If the memory _is_ stable, then we are fine to add a direct reference to
it, and can lose the extra xstrdup() here. Only the caller knows for
sure, so we should be respecting their value of strdup_strings (so lose
the xstrdup, but keep calling string_list_append()).

In practice, I suspect the memory _is_ stable, because we are generally
parsing command-line arguments. But it does not hurt to stay on the
conservative side, and always make a copy (in case we are parsing
something besides the global argv array) . Apparently I am the original
author of this code, in c8ba163 (parse-options: add OPT_STRING_LIST
helper, 2011-06-09), but there's no mention of this point there, in the
list archives, or in my brain.

So if we are doing the conservative thing, then I think the resulting
code should either look like:

  if (!v->strdup_strings)
	die("BUG: OPT_STRING_LIST should always use strdup_strings");
  string_list_append(v, arg);

or:

  /* silently enable for convenience */
  v->strdup_strings = 1;
  string_list_append(v, arg);

Of the two, I like the top one as it is less magical, but it would
require adjusting the initialization of the string-list for most of the
callers.

-Peff

  reply	other threads:[~2016-06-12 22:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 11:57 [PATCH] parse-options-cb.c: use string_list_append_nodup in OPT_STRING_LIST() Nguyễn Thái Ngọc Duy
2016-06-12 22:03 ` Jeff King [this message]
2016-06-13  0:08   ` Duy Nguyen
2016-06-13  5:32     ` [PATCH 0/3] fix parse-opt string_list leaks Jeff King
2016-06-13  5:39       ` [PATCH 1/3] parse_opt_string_list: stop allocating new strings Jeff King
2016-06-13  5:39       ` [PATCH 2/3] interpret-trailers: don't duplicate option strings Jeff King
2016-06-13  5:39       ` [PATCH 3/3] blame,shortlog: don't make local option variables static Jeff King
2016-06-14  4:32         ` Eric Sunshine
2016-06-14  5:05           ` Jeff King
2016-08-02 10:52             ` [PATCH] blame: drop strdup of string literal Jeff King
2016-08-03  7:36               ` Eric Sunshine
2016-06-13  9:36       ` [PATCH 0/3] fix parse-opt string_list leaks Duy Nguyen
2016-06-13 10:04         ` [PATCH 4/3] use string_list initializer consistently Jeff King
2016-06-13 11:31           ` Duy Nguyen
2016-06-13 17:32             ` Jeff King

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=20160612220316.GB5428@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=pclouds@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.