Am 19.09.19 um 23:47 schrieb SZEDER Gábor:
> The 'if (deref) { ... }' condition near the beginning of the recursive
> name_rev() function can only ever be true in the first invocation,
> because the 'deref' parameter is always 0 in the subsequent recursive
> invocations.
>
> Extract this condition from the recursion into name_rev()'s caller and
> drop the function's 'deref' parameter. This makes eliminating the
> recursion a bit easier to follow, and it will be moved back into
> name_rev() after the recursion is elminated.
>
> Furthermore, drop the condition that die()s when both 'deref' and
> 'generation' are non-null (which should have been a BUG() to begin
> with).
>
> Note that this change reintroduces the memory leak that was plugged in
> in commit 5308224633 (name-rev: avoid leaking memory in the `deref`
> case, 2017-05-04), but a later patch in this series will plug it in
> again.
>
> Signed-off-by: SZEDER Gábor <szeder....@gmail.com>
> ---
> builtin/name-rev.c | 27 ++++++++++-----------------
> 1 file changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> index cb8ac2fa64..42cea5c881 100644
> --- a/builtin/name-rev.c
> +++ b/builtin/name-rev.c
> @@ -102,30 +102,19 @@ static struct rev_name *create_or_update_name(struct
> commit *commit,
>
> static void name_rev(struct commit *commit,
> const char *tip_name, timestamp_t taggerdate,
> - int generation, int distance, int from_tag,
> - int deref)
> + int generation, int distance, int from_tag)
> {
> struct commit_list *parents;
> int parent_number = 1;
> - char *to_free = NULL;
>
> parse_commit(commit);
>
> if (commit->date < cutoff)
> return;
>
> - if (deref) {
> - tip_name = to_free = xstrfmt("%s^0", tip_name);
> -
> - if (generation)
> - die("generation: %d, but deref?", generation);
> - }
> -
> if (!create_or_update_name(commit, tip_name, taggerdate, generation,
> - distance, from_tag)) {
> - free(to_free);
> + distance, from_tag))
> return;
> - }
>
> for (parents = commit->parents;
> parents;
> @@ -144,11 +133,11 @@ static void name_rev(struct commit *commit,
>
> name_rev(parents->item, new_name, taggerdate, 0,
> distance + MERGE_TRAVERSAL_WEIGHT,
> - from_tag, 0);
> + from_tag);
> } else {
> name_rev(parents->item, tip_name, taggerdate,
> generation + 1, distance + 1,
> - from_tag, 0);
> + from_tag);
> }
> }
> }
> @@ -280,12 +269,16 @@ static int name_ref(const char *path, const struct
> object_id *oid, int flags, vo
> if (o && o->type == OBJ_COMMIT) {
> struct commit *commit = (struct commit *)o;
> int from_tag = starts_with(path, "refs/tags/");
> + const char *tip_name;
This should not be const because you allocate the buffer it points to
right here in the function, in each execution path.
>
> if (taggerdate == TIME_MAX)
> taggerdate = commit->date;
> path = name_ref_abbrev(path, can_abbreviate_output);
> - name_rev(commit, xstrdup(path), taggerdate, 0, 0,
> - from_tag, deref);
> + if (deref)
> + tip_name = xstrfmt("%s^0", path);
> + else
> + tip_name = xstrdup(path);
> + name_rev(commit, tip_name, taggerdate, 0, 0, from_tag);
tip_name should be free(3)'d here. Except we can't do that because
name_rev() sometimes stores that pointer in a commit slab. Ugh.
If the (re)introduced leak doesn't impact performance and memory
usage too much then duplicating tip_name again in name_rev() or
rather your new create_or_update_name() would likely make the
lifetimes of those string buffers easier to manage.
> }
> return 0;
> }
>
