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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 05 2022, Taylor Blau wrote:

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

I'm not saying you *should*, but now that we use C99 macros we *could*
also make the "1" an optional argument. I.e. these would be the same
thing:

	CALLOC(x)
	CALLOC(x, 1)

And you could also do:

	CALLOC(x, 123)

Whether that makes the interface even nastier is another matter.

That can be done by dispatching to an underlying function, and defining
the macro as:

	#define CALLOC(...) mycallocfn_1(__VA_ARGS__, NULL)

I.e. for the above you'd get either "x, NULL, NULL", "x, 1, NULL", or
"x, 123, NULL". The function could then manually check the arity.

Maybe I've just been corrupted by reading the P99 library :)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux