git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Martin Ågren" <martin.agren@gmail.com>,
	git <git@vger.kernel.org>, "Heiko Voigt" <hvoigt@hvoigt.net>
Subject: Re: [PATCH 02/10] string-list.h: add string_list_pop function.
Date: Thu, 9 Aug 2018 15:10:21 -0700	[thread overview]
Message-ID: <CAGZ79kaDSkwUqfbtRGtfuLKMQs+JcfA75T2cHNxK52hYP+cF-w@mail.gmail.com> (raw)
In-Reply-To: <20180809215637.GA12441@sigill.intra.peff.net>

On Thu, Aug 9, 2018 at 2:56 PM Jeff King <peff@peff.net> wrote:

>
> I think you could have helpers to spell the two lines above even more
> nicely:
>
>   while (list->nr) {
>         work_on(list_top(list));
>         list_pop(list); /* note this doesn't return anything! */
>   }
>
> But yes, it's not possible with the current functions.

I like this one most, and as we manage our own memory via the
alloc variable we also would not see a lot of memory churn for constant
push/pop traffic.

> You can also use a list.h linked-list. Then removal from the list and
> freeing are two separate operations (but it exercises your malloc a lot
> more if you're constantly pushing and popping).

For that I'd have to define my own type derived from list.h to carry
the string and the util pointer, which looks very similar to the string_list
we already have from a users POV.

> > > 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);
> >
> > Another way would be to use
> >
> >   string_list_pop(&list, &string_dst, &util_dst);
> > i.e.
> >   /* Returns 0 if the dst was filled */
> >   int (struct string_list *, char **, void**)
> >
> > as then we do not expose the internals and would not have issues
> > with reallocs.
>
> Yes, I almost suggested that, but there's the question of memory
> ownership of string_dst. Does it need freed or not? Is that answer
> dependent on the strdup_strings flag?

Sure. But as the caller, you should know?
You constructed that string_list.

  reply	other threads:[~2018-08-09 22:10 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
2018-08-09 21:52         ` Stefan Beller
2018-08-09 21:56           ` Jeff King
2018-08-09 22:10             ` Stefan Beller [this message]
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

  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=CAGZ79kaDSkwUqfbtRGtfuLKMQs+JcfA75T2cHNxK52hYP+cF-w@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=martin.agren@gmail.com \
    --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.
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).