All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: "René Scharfe" <l.s.r@web.de>, "Git Mailing List" <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] run-command: introduce CHILD_PROCESS_INIT
Date: Sun, 17 Aug 2014 09:46:42 +0200	[thread overview]
Message-ID: <53F05DE2.5080806@kdbg.org> (raw)
In-Reply-To: <53EFE15B.7030805@web.de>

Am 17.08.2014 00:55, schrieb René Scharfe:
> Most struct child_process variables are cleared using memset right after
> declaration.  Provide a macro, CHILD_PROCESS_INIT, that can be used to
> initialize them statically instead.  That's shorter, doesn't require a
> function call and is slightly more readable (especially given that we
> already have similar macros like STRBUF_INIT, ARGV_ARRAY_INIT etc.).

This is a step in the right direction, IMO. This way to initialize the
struct feels mucth better because it does not depend on that the bit
pattern of the NULL pointer is all zeros.

> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---
>  Documentation/technical/api-run-command.txt |  4 ++--
>  archive-tar.c                               |  3 +--
>  builtin/add.c                               |  3 +--
>  builtin/commit.c                            |  3 +--
>  builtin/help.c                              |  3 +--
>  builtin/merge.c                             |  3 +--
>  builtin/notes.c                             |  3 +--
>  builtin/remote-ext.c                        |  3 +--
>  builtin/repack.c                            |  3 +--
>  builtin/replace.c                           |  4 ++--
>  builtin/verify-pack.c                       |  3 +--
>  bundle.c                                    |  6 ++----
>  connected.c                                 |  3 +--
>  convert.c                                   |  3 +--
>  credential-cache.c                          |  3 +--
>  credential.c                                |  3 +--
>  daemon.c                                    |  8 +++-----
>  diff.c                                      |  3 +--
>  editor.c                                    |  3 +--
>  fetch-pack.c                                |  3 +--
>  gpg-interface.c                             |  6 ++----
>  http-backend.c                              |  3 +--
>  http.c                                      |  3 +--
>  imap-send.c                                 |  2 +-
>  prompt.c                                    |  3 +--
>  remote-curl.c                               |  3 +--
>  remote-testsvn.c                            |  3 +--
>  run-command.h                               |  2 ++
>  send-pack.c                                 |  3 +--
>  submodule.c                                 | 21 +++++++--------------
>  test-run-command.c                          |  4 +---
>  test-subprocess.c                           |  3 +--
>  transport.c                                 | 12 ++++--------
>  upload-pack.c                               |  3 +--
>  wt-status.c                                 |  3 +--
>  35 files changed, 51 insertions(+), 93 deletions(-)

You missed a few instances in builtin/receive-pack.c. Is this deliberate?

Another one is in transport-helper.c::fetch_with_import() that is
currently initialized in get_importer(), and another one in
push_refs_with_export() that is initialized in get_exporter().

Should the static struct child_process variables in pager.c and
connect.c use the macro? It would just be for completeness, but does not
change the correctness. I dunno.

> diff --git a/run-command.h b/run-command.h
> index ea73de3..95a8fb8 100644
> --- a/run-command.h
> +++ b/run-command.h
> @@ -44,6 +44,8 @@ struct child_process {
>  	unsigned clean_on_exit:1;
>  };
>  
> +#define CHILD_PROCESS_INIT { NULL }

I would have expected this to read

#define CHILD_PROCESS_INIT { NULL, ARGV_ARRAY_INIT }

It does change the bit pattern of the initialized struct child_process
because ARGV_ARRAY_INIT uses a non-NULL address. But IMHO
ARGV_ARRAY_INIT should be used here as a defensive measure.

-- Hannes

  parent reply	other threads:[~2014-08-17  7:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-16 22:55 [PATCH] run-command: introduce CHILD_PROCESS_INIT René Scharfe
2014-08-17  7:12 ` Jeff King
2014-08-17  7:25   ` René Scharfe
2014-08-17  7:29     ` Jeff King
2014-08-17  7:46 ` Johannes Sixt [this message]
2014-08-17  8:48   ` Jeff King
2014-08-18 16:59     ` Junio C Hamano
2014-08-19 19:09       ` [PATCH v2 1/4] " René Scharfe
2014-08-19 19:10       ` [PATCH v2 2/4] run-command: introduce child_process_init() René Scharfe
2014-08-19 19:11       ` [PATCH v2 3/4] run-command: call run_command_v_opt_cd_env() instead of duplicating it René Scharfe
2014-08-19 19:11       ` [PATCH v2 4/4] run-command: inline prepare_run_command_v_opt() René Scharfe

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=53F05DE2.5080806@kdbg.org \
    --to=j6t@kdbg.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.