Re: [PATCH v2 05/25] sequencer: allow the sequencer to take custody of malloc()ed data
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Oct 5, 2016, 11:41 UTC
- Message-ID
- <alpine.DEB.2.20.1610051338530.35196@virtualbox>
- In-Reply-To
- <xmqqzinc295y.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 12 Sep 2016, Junio C Hamano wrote:
Show 19 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves
> > like a one-shot command when it reads its configuration: memory is
> > allocated and released only when the command exits.
> >
> > This is kind of okay for git-cherry-pick, which *is* a one-shot
> > command. All the work to make the sequencer its work horse was
> > done to allow using the functionality as a library function, though,
> > including proper clean-up after use.
> >
> > This patch introduces an API to pass the responsibility of releasing
> > certain memory to the sequencer. Example:
> >
> > const char *label =
> > sequencer_entrust(opts, xstrfmt("From: %s", email));
>
> I thought we (not just me) were already pretty clear during the last
> round of review that we will not want this entrust() thing.That does not match my understanding.
The problem is that we are building functionality for libgit.a, not merely for a builtin that we know will simply exit() and take all allocated memory with it.
The additional problem is that the sequencer was *already* meant for libgit.a, yet simply strdup()s data left and right and assigns it to const fields, purposefully wasting memory.
Sure, I can leave those memory leaks in, but then I also have to introduce new ones via the rebase -i support.
If you prefer to accept such sloppy work, I will change it of course, feeling dirty that it has my name on it.
Ciao, Dscho