git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Andrey Okoshkin <a.okoshkin@samsung.com>
Cc: "Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>,
	"Martin Ågren" <martin.agren@gmail.com>,
	"Stefan Beller" <sbeller@google.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	vmiklos@frugalware.org
Subject: Re: [PATCH v2] merge-recursive: check GIT_MERGE_VERBOSITY only once
Date: Wed, 25 Oct 2017 07:53:07 -0400	[thread overview]
Message-ID: <CAPig+cRq1AEOgDoXeH-hDMvhEMnfiNK5CuSBbbio-mbHros=QQ@mail.gmail.com> (raw)
In-Reply-To: <38a80069-abdb-0646-a20c-eca39dd4f519@samsung.com>

On Wed, Oct 25, 2017 at 7:39 AM, Andrey Okoshkin <a.okoshkin@samsung.com> wrote:
> Check 'GIT_MERGE_VERBOSITY' environment variable only once in
> init_merge_options().
> Consequential call of getenv() may return NULL pointer.

It would be particularly nice to have a more detailed explanation in
the commit message of the potential problem this patch is trying to
solve. Given the amount of discussion, thus far, surrounding such a
simple patch, this cryptic warning about getenv() returning NULL upon
second invocation is insufficient to explain why this patch is
desirable; it merely leads to a lot of head-scratching.

> However the stored pointer to the obtained getenv() result may be invalidated
> by some other getenv() call as getenv() is not thread-safe.

This is even more cryptic, as it appears to be arguing for or against
_something_ (it's not clear what) and it seems to be talking about a
facet of the existing code, rather than explaining why the updated
code consumes its 'merge_verbosity' value as early as possible after
being assigned. Perhaps this part could be reworded something like
this:

    Instead, call getenv() only once, storing its value and
    consulting it as many times as needed. This update takes care
    to consume the value returned by getenv() without any
    intervening calls to getenv(), setenv(), unsetenv(), or
    putenv(), any of which might invalidate the pointer returned
    by the initial call.

> Signed-off-by: Andrey Okoshkin <a.okoshkin@samsung.com>
> Reviewed-by: Stefan Beller <sbeller@google.com>

As this patch is semantically quite different from the original to
which Stefan gave his Reviewed-by: (and which other people argued
against), it might be better omit this footer and let him re-give it
if he so desires.

> ---
> Changes since the previous patch:
> * no actions are taken between the merge_verbosity assignment and check.
>  merge-recursive.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 1494ffdb8..60084e3a0 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -2163,6 +2163,7 @@ static void merge_recursive_config(struct merge_options *o)
>
>  void init_merge_options(struct merge_options *o)
>  {
> +       const char *merge_verbosity;
>         memset(o, 0, sizeof(struct merge_options));
>         o->verbosity = 2;
>         o->buffer_output = 1;
> @@ -2171,9 +2172,9 @@ void init_merge_options(struct merge_options *o)
>         o->renormalize = 0;
>         o->detect_rename = 1;
>         merge_recursive_config(o);
> -       if (getenv("GIT_MERGE_VERBOSITY"))
> -               o->verbosity =
> -                       strtol(getenv("GIT_MERGE_VERBOSITY"), NULL, 10);
> +       merge_verbosity = getenv("GIT_MERGE_VERBOSITY");
> +       if (merge_verbosity)
> +               o->verbosity = strtol(merge_verbosity, NULL, 10);
>         if (o->verbosity >= 5)
>                 o->buffer_output = 0;
>         strbuf_init(&o->obuf, 0);
> --
> 2.14.3

  reply	other threads:[~2017-10-25 11:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20171024152727epcas2p4fb7dcf147e44aadf7733098151d469a5@epcas2p4.samsung.com>
2017-10-24 15:27 ` [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once Andrey Okoshkin
2017-10-24 16:28   ` Stefan Beller
2017-10-24 16:45     ` Eric Sunshine
2017-10-24 17:11       ` Martin Ågren
2017-10-24 19:52         ` Jeff King
2017-10-25  1:48           ` Junio C Hamano
2017-10-25  4:07             ` Eric Sunshine
2017-10-25  7:27               ` Jeff King
2017-10-25 11:39                 ` [PATCH v2] " Andrey Okoshkin
2017-10-25 11:53                   ` Eric Sunshine [this message]
2017-10-25 12:27                     ` Andrey Okoshkin
2017-10-25 13:03                     ` [PATCH v3] " Andrey Okoshkin
2017-10-27 17:29                       ` Stefan Beller
2017-10-30  7:42                         ` [PATCH v4] " Andrey Okoshkin
2017-10-31  1:42                           ` Junio C Hamano
2017-10-31  2:26                             ` Junio C Hamano
2017-10-31  7:13                               ` Andrey Okoshkin
2017-10-31  7:20                                 ` Junio C Hamano
2017-10-31  9:09                                   ` [PATCH v5] " Andrey Okoshkin
2017-10-25 11:13           ` [PATCH] " Andrey Okoshkin
2017-10-25 10:49       ` Andrey Okoshkin
2017-10-25 10:49     ` Andrey Okoshkin

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='CAPig+cRq1AEOgDoXeH-hDMvhEMnfiNK5CuSBbbio-mbHros=QQ@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=a.okoshkin@samsung.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.agren@gmail.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    --cc=vmiklos@frugalware.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.
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).