git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
	"Stefan Beller" <sbeller@google.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	hvoigt@hvoigt.net
Subject: Re: [PATCH 02/10] string-list.h: add string_list_pop function.
Date: Thu, 9 Aug 2018 17:41:48 -0400	[thread overview]
Message-ID: <20180809214148.GD11342@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqzhxv9qkj.fsf@gitster-ct.c.googlers.com>

On Thu, Aug 09, 2018 at 02:29:32PM -0700, Junio C Hamano wrote:

> >> +struct string_list_item *string_list_pop(struct string_list *list)
> >> +{
> >> +       if (list->nr == 0)
> >> +               return 0;
> >
> > return NULL, not 0.
> 
> It is OK to return NULL, which may make the caller a bit simpler,
> i.e.
> 
> 	while (item = list_pop(list))
> 		work_on(item);
> 
> but if we consider it a good discipline for the caller to see if
> there are still things on the stack before attempting to pop, then
> instead of returning NULL, we can have BUG("") there, which requires
> the caller to be more like this:
> 
> 	while (list->nr)
> 		work_on(list_pop(list));
> 
> which is not so bad.

In many cases you can just do:

  while (list->nr) {
	work_on(list->items[list->nr - 1]);
	list_remove(list, list->nr - 1);
  }

and then all of those memory ownership issues like:

> > The memory ownership is now with the caller. That is, the caller needs
> > to check/know `list->strdup_strings` and know `free_util` to be able to
> > properly free all memory.
> 
> > OTOH, the pointer returned by this function is only guaranteed to be
> > valid until you start inserting into the list (well, you can do one
> > insertion per pop without worrying, but that's quite detailed
> > implementation knowledge).
> 
> Yes, it is a more grave limitation when using string_list as a
> stack.  A single realloc() and you are dead X-<.

just go away. :)

Where that falls down is if you really need work_on() to put more items
on the stack, but only after you've removed the current top. But then
writing it out may still be nicer, because it makes it clear you have to
do:

  const char *cur_string = xstrdup(list->items[list->nr-1].string);

if you want the data to live past the removal.

-Peff

  reply	other threads:[~2018-08-09 21:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-08 22:17 [RFC PATCH 00/10] fetch: make sure submodule oids are fetched Stefan Beller
2018-08-08 22:17 ` [PATCH 01/10] string_list: print_string_list to use trace_printf Stefan Beller
2018-08-09 21:16   ` Junio C Hamano
2018-08-09 21:40     ` Stefan Beller
2018-08-08 22:17 ` [PATCH 02/10] string-list.h: add string_list_pop function Stefan Beller
2018-08-09  7:35   ` Martin Ågren
2018-08-09 21:29     ` Junio C Hamano
2018-08-09 21:41       ` Jeff King [this message]
2018-08-09 21:52         ` Stefan Beller
2018-08-09 21:56           ` Jeff King
2018-08-09 22:10             ` Stefan Beller
2018-08-08 22:17 ` [PATCH 03/10] sha1-array: provide oid_array_remove_if Stefan Beller
2018-08-09  7:39   ` Martin Ågren
2018-08-09 17:25     ` Stefan Beller
2018-08-09 19:24       ` Jeff King
2018-08-09 21:46         ` Junio C Hamano
2018-08-09 21:44   ` Junio C Hamano
2018-08-08 22:17 ` [PATCH 04/10] submodule.c: convert submodule_move_head new argument to object id Stefan Beller
2018-08-09 22:00   ` Junio C Hamano
2018-08-08 22:17 ` [PATCH 05/10] submodule.c: fix indentation Stefan Beller
2018-08-08 22:17 ` [PATCH 06/10] submodule.c: sort changed_submodule_names before searching it Stefan Beller
2018-08-08 22:17 ` [PATCH 07/10] submodule: move global changed_submodule_names into fetch submodule struct Stefan Beller
2018-08-08 22:17 ` [PATCH 08/10] submodule.c: do not copy around submodule list Stefan Beller
2018-08-08 22:17 ` [PATCH 09/10] submodule: fetch in submodules git directory instead of in worktree Stefan Beller
2018-08-08 22:17 ` [PATCH 10/10] fetch: retry fetching submodules if sha1 were not fetched Stefan Beller
2018-08-09  7:50   ` Martin Ågren
2018-08-09 17:42     ` Stefan Beller

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=20180809214148.GD11342@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=martin.agren@gmail.com \
    --cc=sbeller@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).