> Dmitry S. Dolzhenko (14):
> builtin/pack-objects.c: use ALLOC_GROW() in check_pbase_path()
> bundle.c: use ALLOC_GROW() in add_to_ref_list()
> cache-tree.c: use ALLOC_GROW() in find_subtree()
> commit.c: use ALLOC_GROW() in register_commit_graft()
> diff.c: use ALLOC_GROW()
> diffcore-rename.c: use ALLOC_GROW()
> patch-ids.c: use ALLOC_GROW() in add_commit()
> replace_object.c: use ALLOC_GROW() in register_replace_object()
> reflog-walk.c: use ALLOC_GROW()
> dir.c: use ALLOC_GROW() in create_simplify()
> attr.c: use ALLOC_GROW() in handle_attr_line()
> builtin/mktree.c: use ALLOC_GROW() in append_to_tree()
> read-cache.c: use ALLOC_GROW() in add_index_entry()
> sha1_file.c: use ALLOC_GROW() in pretend_sha1_file()
All looked cleanly done.
The resulting code of 1, 3, 4, 6 and 8 share this pattern:
ALLOC_GROW(table, number + 1, alloc);
number++;
which may be easier to understand if done the other way around:
number++;
ALLOC_GROW(table, number, alloc);
That is, "we know we want one more, so make sure they fit in the
table".
But that is just a minor issue; I suspect many existing callsites to
ALLOC_GROW() already follow the former pattern, and if we decide to
to switch the former to the latter, we shouldn't be doing so within
this series (we should do that as a separate series on top of this).
Thanks; will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html