Jeff King <peff@xxxxxxxx> 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 <peff@xxxxxxxx>
> ---
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html