Thread (2 messages) 2 messages, 2 authors, 2021-11-22

Re: [PATCH 3/5] run-command API users: use strvec_pushv(), not argv assignment

From: Junio C Hamano <hidden>
Date: 2021-11-22 21:19:49

Possibly related (same subject, not in this thread)

Ævar Arnfjörð Bjarmason  [off-list ref] writes:
quoted hunk
diff --git a/add-patch.c b/add-patch.c
index 8c41cdfe39b..573eef0cc4a 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -413,7 +413,7 @@ static int parse_diff(struct add_p_state *s, const struct pathspec *ps)
 		strvec_push(&args, ps->items[i].original);
 
 	setup_child_process(s, &cp, NULL);
-	cp.argv = args.v;
+	strvec_pushv(&cp.args, args.v);
 	res = capture_command(&cp, plain, 0);
 	if (res) {
 		strvec_clear(&args);
@@ -431,7 +431,7 @@ static int parse_diff(struct add_p_state *s, const struct pathspec *ps)
 
 		setup_child_process(s, &colored_cp, NULL);
 		xsnprintf((char *)args.v[color_arg_index], 8, "--color");
-		colored_cp.argv = args.v;
+		strvec_pushv(&colored_cp.args, args.v);
 		colored = &s->colored;
 		res = capture_command(&colored_cp, colored, 0);
 		strvec_clear(&args);
We used to use the caller-supplied args, run-command API borrowed
that strvec by pointing at cp.argv, and because it is borrowed,
capture_command() did not use cp.args/cp.env_array and there was no
leak inside run-command API side, whether capture_command succeeded
or failed.  The code was using its own args, so it already correctly
releases it (we can see one such strvec_clear() here).
 
OK.

I gave the remainder only a cursory look so I cannot call it quite
"reviewed", but presumably all the other changes in this patch are
the same way?

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help