All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] strbuf: add xstrdup_fmt helper
Date: Wed, 18 Jun 2014 15:32:08 -0700	[thread overview]
Message-ID: <xmqq7g4dj1cn.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140618200133.GA23057@sigill.intra.peff.net> (Jeff King's message of "Wed, 18 Jun 2014 16:01:34 -0400")

Jeff King <peff@peff.net> writes:

> You can use a strbuf to build up a string from parts, and
> then detach it. In the general case, you might use multiple
> strbuf_add* functions to do the building. However, in many
> cases, a single strbuf_addf is sufficient, and we end up
> with:
>
>   struct strbuf buf = STRBUF_INIT;
>   ...
>   strbuf_addf(&buf, fmt, some, args);
>   str = strbuf_detach(&buf, NULL);
>
> We can make this much more readable (and avoid introducing
> an extra variable, which can clutter the code) by
> introducing a convenience function:
>
>   str = xstrdup_fmt(fmt, some, args);
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I'm open to suggestions on the name. This really is the same thing
> conceptually as the GNU asprintf(), but the interface is different (that
> function takes a pointer-to-pointer as an out-parameter, and returns the
> number of characters return).

Naming it with anything "dup" certainly feels wrong.  The returned
string is not a duplicate of anything.

To me, the function feels like an "sprintf done right"; as you said,
the best name for "printf-like format into an allocated piece of
memory" is unfortunately taken as asprintf(3).

I wonder if our callers can instead use asprintf(3) with its
slightly more quirky API (and then we supply compat/asprintf.c for
non-GNU platforms).  Right now we only have three call sites, but if
we anticipate that "printf-like format into an allocated piece of
memory" will prove be generally useful in our code base, following
an API that other people already have established may give our
developers one less thing that they have to learn.

As usual, I would expect we would have xasprintf wrapper around it
to die instead of returning -1 upon allocation failure.

The call sites do not look too bad (see below) if we were to go that
route instead.


 remote.c       |  2 +-
 unpack-trees.c | 10 ++++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/remote.c b/remote.c
index b46f467..87fa7ec 100644
--- a/remote.c
+++ b/remote.c
@@ -185,7 +185,7 @@ static struct branch *make_branch(const char *name, int len)
 		ret->name = xstrndup(name, len);
 	else
 		ret->name = xstrdup(name);
-	ret->refname = xstrdup_fmt("refs/heads/%s", ret->name);
+	asprintf(&ret->refname, "refs/heads/%s", ret->name);
 
 	return ret;
 }
diff --git a/unpack-trees.c b/unpack-trees.c
index dd1e06e..d6a07b8 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -63,8 +63,8 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
 			"Please, commit your changes or stash them before you can %s.";
 	else
 		msg = "Your local changes to the following files would be overwritten by %s:\n%%s";
-	msgs[ERROR_WOULD_OVERWRITE] = msgs[ERROR_NOT_UPTODATE_FILE] =
-		xstrdup_fmt(msg, cmd, cmd2);
+	xasprintf(&msgs[ERROR_WOULD_OVERWRITE], msg, cmd, cmd2);
+	msgs[ERROR_NOT_UPTODATE_FILE] =	msgs[ERROR_WOULD_OVERWRITE];
 
 	msgs[ERROR_NOT_UPTODATE_DIR] =
 		"Updating the following directories would lose untracked files in it:\n%s";
@@ -75,8 +75,10 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
 	else
 		msg = "The following untracked working tree files would be %s by %s:\n%%s";
 
-	msgs[ERROR_WOULD_LOSE_UNTRACKED_REMOVED] = xstrdup_fmt(msg, "removed", cmd, cmd2);
-	msgs[ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN] = xstrdup_fmt(msg, "overwritten", cmd, cmd2);
+	xasprintf(&msgs[ERROR_WOULD_LOSE_UNTRACKED_REMOVED],
+		 msg, "removed", cmd, cmd2);
+	xasprintf(&msgs[ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN],
+		 msg, "overwritten", cmd, cmd2);
 
 	/*
 	 * Special case: ERROR_BIND_OVERLAP refers to a pair of paths, we

  reply	other threads:[~2014-06-18 22:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 20:00 [PATCH 0/2] dropping manual malloc calculations Jeff King
2014-06-18 20:01 ` [PATCH 1/2] strbuf: add xstrdup_fmt helper Jeff King
2014-06-18 22:32   ` Junio C Hamano [this message]
2014-06-19  9:05     ` Jeff King
2014-06-19 16:49       ` Junio C Hamano
2014-06-19 21:16         ` [PATCH v2] dropping manual malloc calculations Jeff King
2014-06-19 21:18           ` [PATCH v2 01/10] strbuf: add xstrfmt helper Jeff King
2014-06-19 21:19           ` [PATCH v2 02/10] use xstrfmt in favor of manual size calculations Jeff King
2014-06-19 21:19           ` [PATCH v2 03/10] use xstrdup instead of xmalloc + strcpy Jeff King
2014-06-19 21:24           ` [PATCH v2 04/10] use xstrfmt to replace xmalloc + sprintf Jeff King
2014-06-19 21:26           ` [PATCH v2 05/10] use xstrfmt to replace xmalloc + strcpy/strcat Jeff King
2014-06-19 21:28           ` [PATCH v2 06/10] setup_git_env: use git_pathdup instead of xmalloc + sprintf Jeff King
2014-06-23 10:21             ` Eric Sunshine
2014-06-23 22:43               ` Junio C Hamano
2014-06-24 13:02               ` Duy Nguyen
2014-06-24 13:30             ` Duy Nguyen
2014-06-24 20:58               ` Jeff King
2014-06-25 12:37                 ` Duy Nguyen
2014-06-25 17:20                 ` Junio C Hamano
2014-06-25 17:22                   ` Jeff King
2014-06-25 19:54                     ` Junio C Hamano
2014-06-19 21:28           ` [PATCH v2 07/10] sequencer: use argv_array_pushf Jeff King
2014-06-19 21:29           ` [PATCH v2 08/10] merge: use argv_array when spawning merge strategy Jeff King
2014-06-19 21:29           ` [PATCH v2 09/10] walker_fetch: fix minor memory leak Jeff King
2014-06-19 21:30           ` [PATCH v2 10/10] unique_path: fix unlikely heap overflow Jeff King
2014-06-19 16:52       ` [PATCH 1/2] strbuf: add xstrdup_fmt helper René Scharfe
2014-06-18 20:02 ` [PATCH 2/2] use xstrdup_fmt in favor of manual size calculations 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=xmqq7g4dj1cn.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.