Re: [PATCH] git-compat-util.h: introduce CALLOC(x)
- From
Jeff King <peff@peff.net>
- Date
- Dec 7, 2022, 06:08 UTC
- Message-ID
- <Y5Aty8p4617CZu1C@coredump.intra.peff.net>
- In-Reply-To
- <Y4/8ilFBfGApR8YR@nand.local>
On Tue, Dec 06, 2022 at 09:38:02PM -0500, Taylor Blau wrote:
Show 21 quoted lines
> On Tue, Dec 06, 2022 at 10:35:54AM +0900, Junio C Hamano wrote: > > Jeff King <peff@peff.net> writes: > > > > > So you can think of "allocate this one element and zero it" as "calloc, > > > but don't multiply" or as "malloc, but zero". Naming it CALLOC() is > > > thinking of it as the former. If we think of it as the latter it could > > > perhaps be MALLOCZ() or something. I don't know if that name is too > > > subtle or not. We have xmemdupz(), which is basically the same thing; > > > it's only a zero-terminator, but that is because we are writing non-zero > > > bytes in the rest of it. Mostly I'd worry that it is easy to glance past > > > the "Z". > > > > I think the name for the former would be CALLOC_ONE(), as I would > > rephrase it as "calloc, but just one element". I agree MALLOCZ() > > would be fine for the other interpretation, and I do not have much > > problem as much problem with the name as calling it CALLOC(). > > Between CALLOC_ONE() and MALLOCZ(), I prefer the latter for brevity. But > between that and CALLOC(), I prefer the latter, since "CALLOC()" reminds > me of the zero-initialization of calloc()-proper, and the "Z" in > "MALLOCZ()" feels easy-ish to miss.
FWIW, I agree with your preferences here. But if people think CALLOC() is misleading or badly named, I'm OK with MALLOCZ(). I guess maybe it is ALLOCZ() to go with ALLOC_ARRAY(), and a potential ALLOC() if we choose to have one.
-Peff