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