summaryrefslogtreecommitdiff
path: root/Documentation/manpage-bold-literal.xsl
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2014-05-15 04:34:09 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-05-15 09:49:10 -0700
commit1823bea10fceb371c7876e598d2413c85890cafc (patch)
treef88533be0e3416169ef3c2b567aeac8f0a27b055 /Documentation/manpage-bold-literal.xsl
parentrun_column_filter: use argv_array (diff)
downloadtgif-1823bea10fceb371c7876e598d2413c85890cafc.tar.xz
git_connect: use argv_array
This avoids magic numbers when we allocate fixed-size argv arrays, and makes it more obvious that we are not overflowing. It is also the first step to fixing a memory leak. When git_connect returns a child_process struct, the argv array in the struct is dynamically allocated, but the individual strings are not (they are either owned elsewhere, or are freed). Later, in finish_connect, we free the array but leave the strings alone. This works for the child_process created by git_connect, but if we use transport_take_over, we may also end up with a child_process created by transport-helper's get_helper. In that case, the strings are freshly allocated, and we would want to free them. However, we have no idea in finish_connect which type we have. By consistently using run-command's internal argv-array, we do not have to worry about this issue at all; finish_command takes care of it for us, and we can drop our manual free entirely. Note that this actually makes the get_helper leak slightly worse; now we are leaking both the strings and the array. But when we adjust it in a future patch, that leak will go away entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/manpage-bold-literal.xsl')
0 files changed, 0 insertions, 0 deletions