git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
	"Jacob Keller" <jacob.keller@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Jakub Narębski" <jnareb@gmail.com>
Subject: Re: [PATCH v8 18/19] branch: use ref-filter printing APIs
Date: Mon, 12 Dec 2016 11:40:20 -0500	[thread overview]
Message-ID: <20161212164020.btrrg2f62haxt7sh@sigill.intra.peff.net> (raw)
In-Reply-To: <CAOLa=ZT1KN_iw7JzB78hPb-LrY_yaDZk0D+TqY2W9hCOftzumA@mail.gmail.com>

On Mon, Dec 12, 2016 at 09:59:49PM +0530, Karthik Nayak wrote:

> >> > This caller never stores the return value, and it ends up leaking. So I
> >> > wonder if you wanted "static struct strbuf" in the first place (and that
> >> > would explain the strbuf_reset() in your function).
> >>
> >> Ah! Yes this should be 'static struct strbuf' indeed, I blindly copied Junio's
> >> suggestion.
> >>
> >> strbuf_detach() is also a better way to go.
> >
> > One of the other, though. If it's static, then you _don't_ want to
> > detach.
> >
> 
> Wait. Why not? since it gets added to the strbuf's within
> build_format() and that
> value is not needed again, why do we need to re-allocate? we can use the same
> variable again (i.e by keeping it as static).
> 
> I'm sorry, but I didn't get why these two should be mutually exclusive?

What is the memory ownership convention for the return value from the
function?

If the caller should own the memory, then you want to do this:

  char *foo(...)
  {
	struct strbuf buf = STRBUF_INIT;
	... fill up buf ...
	return strbuf_detach(&buf, NULL);
  }

The "detach" disconnects the memory from the strbuf (which is going out
of scope anyway), and the only pointer left to it is in the caller. It's
important to use "detach" here and not just return the pointer, because
that ensures that the returned value is always allocated memory (and
never strbuf_slopbuf).

If the caller should not own the memory, then the function retains
ownership. And you want something like this:

  char *foo(...)
  {
	static struct strbuf buf = STRBUF_INIT;
	strbuf_reset(&buf);
	... fill up buf ...
	return buf.buf;
  }

The same buffer is reused over and over. The "reset" call clears any
leftover bits from the last invocation, and you must _not_ call
strbuf_detach() in the return, as it disconnects the memory from the
strbuf (and so next time you'd end up allocating again, and each return
value becomes a memory leak).

Does that make sense?

-Peff

  reply	other threads:[~2016-12-12 16:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-07 15:36 [PATCH v8 00/19] port branch.c to use ref-filter's printing options Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 01/19] ref-filter: implement %(if), %(then), and %(else) atoms Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 02/19] ref-filter: include reference to 'used_atom' within 'atom_value' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 03/19] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 04/19] ref-filter: modify "%(objectname:short)" to take length Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 05/19] ref-filter: move get_head_description() from branch.c Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 06/19] ref-filter: introduce format_ref_array_item() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 07/19] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 08/19] ref-filter: add support for %(upstream:track,nobracket) Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 09/19] ref-filter: make "%(symref)" atom work with the ':short' modifier Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 10/19] ref-filter: introduce refname_atom_parser_internal() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 11/19] ref-filter: introduce refname_atom_parser() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 12/19] ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 13/19] ref-filter: rename the 'strip' option to 'lstrip' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 14/19] ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 15/19] ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 16/19] ref-filter: allow porcelain to translate messages in the output Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 17/19] branch, tag: use porcelain output Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 18/19] branch: use ref-filter printing APIs Karthik Nayak
2016-12-09 14:03   ` Jeff King
2016-12-12 11:20     ` Karthik Nayak
2016-12-12 12:15       ` Jeff King
2016-12-12 16:29         ` Karthik Nayak
2016-12-12 16:40           ` Jeff King [this message]
2016-12-12 17:18             ` Karthik Nayak
2016-12-07 15:36 ` [PATCH v8 19/19] branch: implement '--format' option Karthik Nayak
2016-12-08  0:01 ` [PATCH v8 00/19] port branch.c to use ref-filter's printing options Jacob Keller
2016-12-08 18:58   ` Junio C Hamano
2016-12-09  1:45     ` Jacob Keller
2016-12-12 10:42   ` Karthik Nayak
2016-12-08 23:58 ` Junio C Hamano
2016-12-12 10:43   ` 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

  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=20161212164020.btrrg2f62haxt7sh@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=jnareb@gmail.com \
    --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.
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).