From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Lukas Fleischer <git@cryptocrack.de>, git@vger.kernel.org
Subject: Re: [PATCH] blame.c: fix garbled error message
Date: Mon, 12 Jan 2015 20:54:27 -0500 [thread overview]
Message-ID: <20150113015427.GA5497@peff.net> (raw)
In-Reply-To: <xmqqzj9n4k11.fsf@gitster.dls.corp.google.com>
On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > As an aside, I have often been tempted to have xstrdup silently
> > propagate a NULL. It would have been the right thing to do here, but
> > maybe there are cases where the segfault is preferable for catching a
> > mistake early (otherwise you might store the NULL and then segfault much
> > later).
>
> Great minds think alike. The sentence after "but maybe ..." was
> what I had in mind as a response in anticipation that somebody might
> suggest that; a separate xstrdup_or_null() might be fine, but I'd
> rather not to have xstrdup() that is _too_ magical.
Yeah. Of course, it is not _that_ many more characters to do a ternary
conditional. I guess the main benefit is that you do not have to repeat
the name of the variable (which lets you reuse a function result
directly, avoiding an explicit temporary).
Here's my attempt. Some cases are a little nicer, but overall, it does
not feel significantly more readable to me. I dunno. I could go either
way. I stuck Lukas's patch on top (modified to use xstrdup_or_null), if
we do want to go that route. Otherwise it needs the ?: treatment.
[1/5]: git-compat-util: add xstrdup_or_null helper
[2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup
[3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup
[4/5]: use xstrdup_or_null to replace ternary conditionals
[5/5]: blame.c: fix garbled error message
next prev parent reply other threads:[~2015-01-13 1:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 21:33 [PATCH] blame.c: fix garbled error message Lukas Fleischer
2015-01-12 19:08 ` Junio C Hamano
2015-01-12 20:40 ` Jeff King
2015-01-12 22:55 ` Junio C Hamano
2015-01-12 23:12 ` Jeff King
2015-01-13 0:11 ` Junio C Hamano
2015-01-13 1:54 ` Jeff King [this message]
2015-01-13 1:57 ` [PATCH 1/5] git-compat-util: add xstrdup_or_null helper Jeff King
2015-01-13 2:21 ` Jonathan Nieder
2015-01-13 2:23 ` Jeff King
2015-01-13 1:58 ` [PATCH 2/5] builtin/apply.c: use xstrdup_or_null instead of null_strdup Jeff King
2015-01-13 1:58 ` [PATCH 3/5] builtin/commit.c: use xstrdup_or_null instead of envdup Jeff King
2015-01-13 1:59 ` [PATCH 4/5] use xstrdup_or_null to replace ternary conditionals Jeff King
2015-01-13 1:59 ` [PATCH 5/5] blame.c: fix garbled error message Jeff King
2015-01-14 14:21 ` [PATCH] " Lukas Fleischer
2015-01-14 17:22 ` Junio C Hamano
2015-01-14 20:49 ` Jeff King
2015-01-14 21:54 ` Junio C Hamano
2015-01-12 23:18 ` Lukas Fleischer
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=20150113015427.GA5497@peff.net \
--to=peff@peff.net \
--cc=git@cryptocrack.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).