From: Heiko Voigt <hvoigt@hvoigt.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Subject: Re: Re: [PATCH v3 5/5] do not die when error in config parsing of buf occurs
Date: Sat, 11 May 2013 10:55:31 +0200 [thread overview]
Message-ID: <20130511085531.GA3670@book-mint> (raw)
In-Reply-To: <20130509223936.GC30774@sigill.intra.peff.net>
On Fri, May 10, 2013 at 12:39:37AM +0200, Jeff King wrote:
> On Thu, May 09, 2013 at 06:21:02PM +0200, Heiko Voigt wrote:
>
> > diff --git a/builtin/config.c b/builtin/config.c
> > index 8d01b7a..de32977 100644
> > --- a/builtin/config.c
> > +++ b/builtin/config.c
> > @@ -219,9 +219,11 @@ static int get_value(const char *key_, const char *regex_)
> > }
> > }
> >
> > - git_config_with_options(collect_config, &values,
> > + ret = git_config_with_options(collect_config, &values,
> > given_config_file, given_config_blob,
> > respect_includes);
> > + if (ret < 0)
> > + goto free_values;
> >
> > ret = !values.nr;
> >
> > @@ -231,6 +233,7 @@ static int get_value(const char *key_, const char *regex_)
> > fwrite(buf->buf, 1, buf->len, stdout);
> > strbuf_release(buf);
> > }
> > +free_values:
> > free(values.items);
> >
> > free_strings:
>
> Hmm. "values" is a strbuf_list. Don't we need to strbuf_release() its
> individual members before freeing it? The writing loop directly above
> your label frees each one after writing. It would probably make sense to
> just split it into two loops, one for writing, and then one for
> free-ing. This is not a critical performance path that we can't iterate
> over the (probably handful of) entries twice.
Thanks for catching that. I missed the strbuf_release in the loop
somehow. Will fix in the next iteration.
> > diff --git a/t/t1307-config-blob.sh b/t/t1307-config-blob.sh
> > index fdc257e..a4929eb 100755
> > --- a/t/t1307-config-blob.sh
> > +++ b/t/t1307-config-blob.sh
> > @@ -55,12 +55,17 @@ test_expect_success 'editing a blob is an error' '
> > test_expect_success 'parse errors in blobs are properly attributed' '
> > cat >config <<-\EOF &&
> > [some]
> > - value = "
> > + value = 1
> > + error = "
> > EOF
> > git add config &&
> > git commit -m broken &&
> >
> > - test_must_fail git config --blob=HEAD:config some.value 2>err &&
> > + test_must_fail git config --blob=HEAD:config some.value 1>out 2>err &&
> > +
> > + # Make sure there is no output of values on stdout
> > + touch out.expect &&
> > + test_cmp out.expect out &&
>
> I'm not clear on what is being tested here. Were we outputting to stdout
> before this patch (I would have thought our die() meant we did not.
We where not outputting to stdout before so the test is correct there as
well. I extended the test when implementing the non-dying version of
git_config_with_options() so I could see the test fail. If just
returning the error it would still output the values read until then. So
if you think that it belongs into the initial version of this test
(maybe including some comment why we need an extra parseable value) I
am happy to move it there.
Cheers Heiko
next prev parent reply other threads:[~2013-05-11 8:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130509154020.GA26423@book-mint>
2013-05-09 16:17 ` [PATCH v3 1/5] config: factor out config file stack management Heiko Voigt
2013-05-09 16:18 ` [PATCH v3 2/5] config: drop cf validity check in get_next_char() Heiko Voigt
2013-05-09 16:19 ` [PATCH v3 3/5] config: make parsing stack struct independent from actual data source Heiko Voigt
2013-05-09 22:21 ` Jeff King
2013-05-09 16:20 ` [PATCH v3 4/5] teach config --blob option to parse config from database Heiko Voigt
2013-05-09 18:23 ` Eric Sunshine
2013-05-09 22:30 ` Jeff King
2013-05-10 15:47 ` Heiko Voigt
2013-05-09 16:21 ` [PATCH v3 5/5] do not die when error in config parsing of buf occurs Heiko Voigt
2013-05-09 18:23 ` Eric Sunshine
2013-05-09 22:39 ` Jeff King
2013-05-11 8:55 ` Heiko Voigt [this message]
2013-05-11 9:59 ` Jeff King
2013-05-11 10:30 ` Heiko Voigt
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=20130511085531.GA3670@book-mint \
--to=hvoigt@hvoigt.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jens.lehmann@web.de \
--cc=peff@peff.net \
--cc=ramsay@ramsay1.demon.co.uk \
/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).