git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Joachim Schmitz" <jojo@schmitz-digital.de>
To: git@vger.kernel.org
Subject: Re: [PATCH 1/2] sequencer: trivial fix
Date: Wed, 29 May 2013 11:58:03 +0200	[thread overview]
Message-ID: <ko4jf7$e4d$1@ger.gmane.org> (raw)
In-Reply-To: 51a568db9c9b8_807b33e18996fa@nysa.mail

Felipe Contreras wrote:
> Junio C Hamano wrote:
>> Neil Horman <nhorman@tuxdriver.com> writes:
>>
>>> On Mon, May 27, 2013 at 11:52:18AM -0500, Felipe Contreras wrote:
>>>> We should free objects before leaving.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>>  sequencer.c | 7 +++++--
>>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/sequencer.c b/sequencer.c
>>>> index ab6f8a7..7eeae2f 100644
>>>> --- a/sequencer.c
>>>> +++ b/sequencer.c
>>>> @@ -626,12 +626,15 @@ static int do_pick_commit(struct commit
>>>>  *commit, struct replay_opts *opts)
>>>>  rerere(opts->allow_rerere_auto); } else {
>>>>  int allow = allow_empty(opts, commit);
>>>> - if (allow < 0)
>>>> - return allow;
>>>> + if (allow < 0) {
>>>> + res = allow;
>>>> + goto leave;
>>>> + }
>>>>  if (!opts->no_commit)
>>>>  res = run_git_commit(defmsg, opts, allow);
>>>>  }
>>>>
>>>> +leave:
>>>>  free_message(&msg);
>>>>  free(defmsg);
>>>>
>>>> --
>>>> 1.8.3.rc3.312.g47657de
>>>>
>>>>
>>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>
>> This is better done without "goto" in general.
>>
>> The other patch 2/2/ adds one more "we need to exit from the middle
>> of the flow" and makes it look handier to add an exit label here,
>> but it would be even better to express the logic of that patch as a
>> normal cascade of if/else if/..., which is small enough and we do
>> not need the "leave:" label.
>
> Linux kernel developers would disagree. In C 'goto' is quite of then
> the only sane option, and you can see 'goto' used in the Linux kernel
> all over the place for that reason.
>
> In this particular case it also makes perfect sense.
>
>> It probably is better to fold this patch into the other one when it
>> is rerolled to correct the option name gotcha "on the tin".
>
> Why? This patch is standalone and fixes an issue that is independent
> of the other patch. Why squash two patches that do *two* different
> things?
>
> Anyway, I'll happily drop this patch if you want this memory leak to
> remain. But then I'll do the same in the other patch.
>
> This mantra of avodiing 'goto' is not helping anybody.

adding 5 letters (to change the next "if" into an "else if") versus your 
addition of several lines and some 15 additional letters (ignoring the 
whitsspace)  is IMHO enough to see what is better?

bye, Jojo 

  reply	other threads:[~2013-05-29  9:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27 16:52 [PATCH 0/2] cherry-pick: a fix and a new option Felipe Contreras
2013-05-27 16:52 ` [PATCH 1/2] sequencer: trivial fix Felipe Contreras
2013-05-28 11:00   ` Neil Horman
2013-05-28 17:04     ` Junio C Hamano
2013-05-29  2:32       ` Felipe Contreras
2013-05-29  9:58         ` Joachim Schmitz [this message]
2013-05-29 10:51           ` Felipe Contreras
2013-05-29 11:13             ` Joachim Schmitz
2013-05-29 11:23               ` Felipe Contreras
2013-05-29 11:29                 ` Joachim Schmitz
2013-05-29 11:37                 ` Joachim Schmitz
2013-05-29 13:13         ` Neil Horman
2013-05-29 13:25   ` Duy Nguyen
2013-05-29 13:34     ` Felipe Contreras
2013-05-29 13:42       ` Duy Nguyen
2013-05-29 13:46         ` Felipe Contreras
2013-05-29 13:54           ` Duy Nguyen
2013-05-29 14:10             ` Felipe Contreras
2013-05-27 16:52 ` [PATCH 2/2] cherry-pick: add --skip-commits option Felipe Contreras
2013-05-28 10:29   ` Joachim Schmitz
2013-05-28 11:06   ` Neil Horman

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='ko4jf7$e4d$1@ger.gmane.org' \
    --to=jojo@schmitz-digital.de \
    --cc=git@vger.kernel.org \
    /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).