Re: [PATCH v4 00/14] Use ALLOC_GROW() instead of inline code

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 3, 2014, 23:02 UTC
Message-ID: <xmqqwqganavy.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1393885922-21616-1-git-send-email-dmitrys.dolzhenko@yandex.ru>

Show 15 quoted lines

> 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.