Re: [PATCH] git-compat-util.h: introduce CALLOC(x)

From: Taylor Blau <me@ttaylorr.com>
Date: Dec 6, 2022, 00:29 UTC
Message-ID: <Y46M4oksPQkqwmTC@nand.local>
In-Reply-To: <xmqqedtdpfoe.fsf@gitster.g>

On Tue, Dec 06, 2022 at 08:57:21AM +0900, Junio C Hamano wrote:

Show 15 quoted lines

> Taylor Blau <me@ttaylorr.com> writes:
>
> > In git.git, it is sometimes common to write something like:
> >
> >     T *ptr;
> >     CALLOC_ARRAY(ptr, 1);
> >
> > ...but that is confusing, since we're not initializing an array.
>
> Given that "man calloc" tells us that calloc takes two parameters,
>
>     void *calloc(size_t nmemb, size_t size);
>
> I personally find CALLOC() that takes only a single parameter and is
> capable only to allocate a single element array very much confusing.

Hmm. I have always considered "calloc" a mental shorthand for "zero initialize some bytes on the heap". It seemed like you were in favor of such a change in:

    https://lore.kernel.org/git/xmqq8rl8ivlb.fsf@gitster.g/

...but it's entirely possible that I misread your message, in which case I would not be sad if you dropped this patch on the floor since I don't feel that strongly about it.

I'd be fine to call it CALLOC_ONE() or something, but I'm not sure at that point if it's significantly better to write "CALLOC_ONE(x)" versus "CALLOC_ARRAY(foo, 1)"

Show 5 quoted lines

> It _might_ be arguable that the order of the parameters CALLOC_ARRAY
> takes should have been reversed in that the number of elements in
> the array should come first just like in calloc(), while the pointer
> that is used to infer the size of an array element should come next,
> but that is water under the bridge.

Yes, I agree that that would be better. But it would be frustrating to make a tree-wide change of that magnitude at this point. So I agree it's water under the bridge ;-).

Thanks, Taylor