summaryrefslogtreecommitdiff
path: root/add-patch.c
diff options
context:
space:
mode:
authorLibravatar Eric Sunshine <sunshine@sunshineco.com>2021-11-25 23:52:16 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-11-25 22:15:07 -0800
commit33c997a411b14b0ac54452d79c6951cbf109475c (patch)
treef6d80e005991cc4bd485d8a7080cb52b943a29ac /add-patch.c
parentSync with 2.34.1 (diff)
downloadtgif-33c997a411b14b0ac54452d79c6951cbf109475c.tar.xz
worktree: stop being overly intimate with run_command() internals
add_worktree() reuses a `child_process` for three run_command() invocations, but to do so, it has overly-intimate knowledge of run-command.c internals. In particular, it knows that it must reset child_process::argv to NULL for each subsequent invocation[*] in order for start_command() to latch the newly-populated child_process::args for each invocation, even though this behavior is not a part of the documented API. Beyond having overly-intimate knowledge of run-command.c internals, the reuse of one `child_process` for three run_command() invocations smells like an unnecessary micro-optimization. Therefore, stop sharing one `child_process` and instead use a new one for each run_command() call. [*] If child_process::argv is not reset to NULL, then subsequent run_command() invocations will instead incorrectly access a dangling pointer to freed memory which had been allocated by child_process::args on the previous run. This is due to the following code in start_command(): if (!cmd->argv) cmd->argv = cmd->args.v; Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'add-patch.c')
0 files changed, 0 insertions, 0 deletions