mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
To: Junio C Hamano <>
Cc:, Jeff King <>
Subject: Re: [PATCH] git-compat-util.h: introduce CALLOC(x)
Date: Mon, 5 Dec 2022 19:29:22 -0500	[thread overview]
Message-ID: <Y46M4oksPQkqwmTC@nand.local> (raw)
In-Reply-To: <xmqqedtdpfoe.fsf@gitster.g>

On Tue, Dec 06, 2022 at 08:57:21AM +0900, Junio C Hamano wrote:
> Taylor Blau <> 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:

...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)"

> 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 ;-).


  reply	other threads:[~2022-12-06  0:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 18:54 [PATCH] git-compat-util.h: introduce CALLOC(x) Taylor Blau
2022-12-05 21:01 ` René Scharfe
2022-12-05 22:36   ` Taylor Blau
2022-12-05 23:12     ` Ævar Arnfjörð Bjarmason
2022-12-06  1:47       ` Jeff King
2022-12-06  1:58         ` Ævar Arnfjörð Bjarmason
2022-12-07  6:02           ` Jeff King
2022-12-07  2:36         ` Taylor Blau
2022-12-07  2:34       ` Taylor Blau
2022-12-07  3:17         ` Ævar Arnfjörð Bjarmason
2022-12-06  1:43     ` Jeff King
2022-12-07  2:29       ` Taylor Blau
2022-12-07  3:51         ` Ævar Arnfjörð Bjarmason
2022-12-05 23:57 ` Junio C Hamano
2022-12-06  0:29   ` Taylor Blau [this message]
2022-12-06  1:21     ` Jeff King
2022-12-06  1:35       ` Junio C Hamano
2022-12-07  2:38         ` Taylor Blau
2022-12-07  6:08           ` Jeff King
2022-12-06  2:12     ` Ævar Arnfjörð Bjarmason
2022-12-07  6:06       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y46M4oksPQkqwmTC@nand.local \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).