Jeff King <p...@peff.net> writes:

> Because the allocator functions for tree, blobs, etc are all
> very similar, we originally used a macro to avoid repeating
> ourselves. Since the prior commit, though, the heavy lifting
> is done by an inline helper function.  The macro does still
> save us a few lines, but at some readability cost.  It
> obfuscates the function definitions (and makes them hard to
> find via grep).
>
> Much worse, though, is the fact that it isn't used
> consistently for all allocators. Somebody coming later may
> be tempted to modify DEFINE_ALLOCATOR, but they would miss
> alloc_commit_node, which is treated specially.
>
> Let's just drop the macro and write everything out
> explicitly.
>
> Signed-off-by: Jeff King <p...@peff.net>
> ---
>  alloc.c | 38 +++++++++++++++++++++++++++-----------
>  1 file changed, 27 insertions(+), 11 deletions(-)
> ...
> +static struct alloc_state blob_state;
> +void *alloc_blob_node(void)
> +{
> +     struct blob *b = alloc_node(&blob_state, sizeof(struct blob));
> +     return b;
> +}

I think the change makes the code nicer overall, but it looks
strange to see a (void *) that was returned by alloc_node()
implicitly casted to (struct blob *) by assignment to b and then
again implicitly casted to (void *) by it being the return type of
the function.

Is there a reason why it is not like so?

        void *alloc_blob_node(void)
        {
                return alloc_node(&blob_state, sizeof(struct blob));
        }

I may have missed previous discussion on it, in which case I'd
apologize in advance.
--
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

Reply via email to