On Tue, 13 Jan 2015 at 02:54:27, Jeff King wrote: > On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote: > > > Jeff King <peff@xxxxxxxx> 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 > Looks good to me! I am not sure whether those patches should be built on top of (a fixed version of) my patch, though, which would make backporting the fix to the maintenance branch straightforward. Junio? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html