Stefan Beller <sbel...@google.com> writes:
> Signed-off-by: Stefan Beller <sbel...@google.com>
> ---
> builtin/commit.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 961e467..da79ac4 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -229,7 +229,7 @@ static int commit_index_files(void)
> static int list_paths(struct string_list *list, const char *with_tree,
> const char *prefix, const struct pathspec *pattern)
> {
> - int i;
> + int i, ret;
> char *m;
>
> if (!pattern->nr)
> @@ -256,7 +256,9 @@ static int list_paths(struct string_list *list, const
> char *with_tree,
> item->util = item; /* better a valid pointer than a
> fake one */
> }
>
> - return report_path_error(m, pattern, prefix);
> + ret = report_path_error(m, pattern, prefix);
> + free(m);
> + return ret;
> }
Looks correct.
A tangent. We may want to move report_path_error() to somewhere
more "common"-ish, like dir.c which is where we have bulk of
pathspec matching infrastructure. Seeing the function used from
builtin/ls-files.c makes me feel dirty.
A further tangent (Duy Cc'ed for this point). We might want to
rethink the interface to ce_path_match() and report_path_error()
so that we do not have to do a separate allocation of "has this
pathspec been used?" array. This was a remnant from the olden days
back when pathspec were mere "const char **" where we did not have
any room to add per-item bit---these days pathspec is repreasented
as an array of "struct pathspec" and we can afford to add a bit
to the structure---which will make this kind of leak much less
likely to happen.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
