From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] use child_process_init() to initialize struct child_process variables
Date: Wed, 29 Oct 2014 13:21:09 -0400 [thread overview]
Message-ID: <20141029172109.GA32234@peff.net> (raw)
In-Reply-To: <54500212.7040603@web.de>
On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
> --- a/bundle.c
> +++ b/bundle.c
> @@ -381,7 +381,7 @@ int create_bundle(struct bundle_header *header, const char *path,
> write_or_die(bundle_fd, "\n", 1);
>
> /* write pack */
> - memset(&rls, 0, sizeof(rls));
> + child_process_init(&rls);
> argv_array_pushl(&rls.args,
> "pack-objects", "--all-progress-implied",
> "--stdout", "--thin", "--delta-base-offset",
I wondered if this one could use CHILD_PROCESS_INIT in the declaration
instead. And indeed, we _do_ use CHILD_PROCESS_INIT there, but we use
the same variable twice for two different child processes in the same
function. Besides variable reuse being slightly confusing, the name
"rls" (which presumably stands for "rev-list" for the first child) means
nothing here, where we are calling "pack-objects". Maybe it would be
cleaner to introduce a second variable?
I also suspect the function would be a lot more readable broken into two
sub-functions (reading from rev-list and writing to pack-objects), but I
did not look closely enough to see whether there were any complicating
factors.
> diff --git a/column.c b/column.c
> index 8082a94..786abe6 100644
> --- a/column.c
> +++ b/column.c
> @@ -374,7 +374,7 @@ int run_column_filter(int colopts, const struct column_options *opts)
> if (fd_out != -1)
> return -1;
>
> - memset(&column_process, 0, sizeof(column_process));
> + child_process_init(&column_process);
> argv = &column_process.args;
>
> argv_array_push(argv, "column");
This one uses a static child_process which needs to be reinitialized on
each run of the function. So it definitely needs child_process_init.
> diff --git a/trailer.c b/trailer.c
> index 8514566..7ff036c 100644
> --- a/trailer.c
> +++ b/trailer.c
> @@ -237,7 +237,7 @@ static const char *apply_command(const char *command, const char *arg)
> strbuf_replace(&cmd, TRAILER_ARG_STRING, arg);
>
> argv[0] = cmd.buf;
> - memset(&cp, 0, sizeof(cp));
> + child_process_init(&cp);
> cp.argv = argv;
> cp.env = local_repo_env;
> cp.no_stdin = 1;
I think this one can use CHILD_PROCESS_INIT in the declaration. I guess
it is debatable whether that is actually preferable, but I tend to think
it is cleaner and less error-prone.
-Peff
next prev parent reply other threads:[~2014-10-29 17:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 20:52 [PATCH] use child_process_init() to initialize struct child_process variables René Scharfe
2014-10-28 21:58 ` mike.gorchak.qnx
2014-10-29 17:21 ` Jeff King [this message]
2014-10-29 19:16 ` Junio C Hamano
2014-10-30 18:07 ` Junio C Hamano
2014-10-30 21:25 ` Jeff King
2014-10-30 18:08 ` [PATCH] bundle: split out a helper function to compute and write prerequisites Junio C Hamano
2014-10-30 21:26 ` Jeff King
2014-10-30 21:35 ` [PATCH] use child_process_init() to initialize struct child_process variables Jeff King
2014-10-31 0:19 ` Philip Oakley
2014-10-31 21:48 ` Junio C Hamano
2014-11-01 3:33 ` Jeff King
2014-11-02 22:54 ` Philip Oakley
2014-11-03 18:26 ` Junio C Hamano
2014-11-03 22:04 ` Jeff King
2014-11-03 23:42 ` Junio C Hamano
2014-11-04 21:56 ` Junio C Hamano
2014-11-04 23:32 ` Jeff King
2014-11-05 0:32 ` Junio C Hamano
2014-11-05 13:41 ` Philip Oakley
2014-11-05 13:35 ` Philip Oakley
2014-11-05 19:35 ` Jeff King
2014-11-05 23:50 ` Philip Oakley
2014-11-09 13:49 ` René Scharfe
2014-11-10 7:14 ` Jeff King
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=20141029172109.GA32234@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
/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).