All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Jeff King <peff@peff.net>, phillip.wood@dunelm.org.uk
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2 4/4] xdiff: introduce XDL_ALLOC_GROW()
Date: Wed, 13 Jul 2022 10:38:13 +0100	[thread overview]
Message-ID: <46f70aff-59f1-01ca-8f1f-b07b230011bc@gmail.com> (raw)
In-Reply-To: <Ys0gerokoiLC9llA@coredump.intra.peff.net>

Hi Peff

It's great to see you back on the list

On 12/07/2022 08:19, Jeff King wrote:
> On Mon, Jul 11, 2022 at 11:00:06AM +0100, Phillip Wood wrote:
> 
>>> But you've also changed every single callsite anyway.
>>>
>>> So why not just change:
>>>
>>>       if (XDL_ALLOC_GROW(recs, ...))
>>>
>>> To:
>>>
>>>       XDL_ALLOC_GROW(recs, ...);
>>>       if (!recs)
>>
>> Because I think it's ugly, we'd never define a function as void(int* result,
>> args...) and I don't think we should do that for a macro where we can avoid
>> it. The existing ALLOC_* macros make sense as statements because they die on
>> failure.
> 
> Those macros are already unlike functions, though. They take a variable
> _name_, not a pointer to a variable, and assign to it. A version which
> looked like a function would have to be:
> 
>    if (XDL_ALLOC_GROW(&recs, ...))
> 
> So in my head I read them as assignment statements already, making the
> expression-like form a bit jarring.

I see what you're saying, I agree it is not exactly analogous. I tend to 
think of assignment as an expression because it returns the value that's 
being assigned, though here it's a bit muddy because the assignment is 
hidden inside the macro and there is no tell-tale '&' as there would be 
if it were calling function.

> Just my two cents. I don't care _too_ much either way, but I'd probably
> be swayed if one implementation is much simpler than the other.

I don't think there is much difference in the complexity in this case. 
In general I think that using a function with a macro wrapper can make 
the implementation more readable as the function it is not littered with 
the extra parentheses and backslashes that the same code in a macro 
requires.

Best Wishes

Phillip

      reply	other threads:[~2022-07-13  9:38 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 15:25 [PATCH 0/3] xdiff: introduce memory allocation macros Phillip Wood via GitGitGadget
2022-06-29 15:25 ` [PATCH 1/3] xdiff: introduce XDL_ALLOC_ARRAY() Phillip Wood via GitGitGadget
2022-06-29 15:25 ` [PATCH 2/3] xdiff: introduce XDL_CALLOC_ARRAY() Phillip Wood via GitGitGadget
2022-06-30 18:17   ` Junio C Hamano
2022-07-06 13:17     ` Phillip Wood
2022-06-29 15:25 ` [PATCH 3/3] xdiff: introduce XDL_ALLOC_GROW() Phillip Wood via GitGitGadget
2022-06-30 10:54   ` Ævar Arnfjörð Bjarmason
2022-06-30 12:03     ` Phillip Wood
2022-06-30 12:38       ` Phillip Wood
2022-06-30 13:25         ` Ævar Arnfjörð Bjarmason
2022-07-06 13:23           ` Phillip Wood
2022-07-07 11:17             ` Ævar Arnfjörð Bjarmason
2022-07-08  9:35               ` Phillip Wood
2022-07-08 14:20                 ` [PATCH 0/7] xdiff: use standard alloc macros, share them via git-shared-util.h Ævar Arnfjörð Bjarmason
2022-07-08 14:20                   ` [PATCH 1/7] xdiff: simplify freeing patterns around xdl_free_env() Ævar Arnfjörð Bjarmason
2022-07-08 14:20                   ` [PATCH 2/7] git-shared-util.h: move "shared" allocation utilities here Ævar Arnfjörð Bjarmason
2022-07-08 14:20                   ` [PATCH 3/7] git-shared-util.h: add G*() versions of *ALLOC_*() Ævar Arnfjörð Bjarmason
2022-07-11 10:06                     ` Phillip Wood
2022-07-08 14:20                   ` [PATCH 4/7] xdiff: use G[C]ALLOC_ARRAY(), not XDL_CALLOC_ARRAY() Ævar Arnfjörð Bjarmason
2022-07-11 10:10                     ` Phillip Wood
2022-07-08 14:20                   ` [PATCH 5/7] xdiff: use GALLOC_GROW(), not XDL_ALLOC_GROW() Ævar Arnfjörð Bjarmason
2022-07-11 10:13                     ` Phillip Wood
2022-07-11 10:48                       ` Ævar Arnfjörð Bjarmason
2022-07-13  9:09                         ` Phillip Wood
2022-07-13 10:48                           ` Ævar Arnfjörð Bjarmason
2022-07-13 13:21                             ` Phillip Wood
2022-07-08 14:20                   ` [PATCH 6/7] xdiff: remove xdl_malloc() wrapper, use malloc(), not xmalloc() Ævar Arnfjörð Bjarmason
2022-07-08 17:42                     ` Phillip Wood
2022-07-08 21:44                       ` Ævar Arnfjörð Bjarmason
2022-07-08 19:35                     ` Jeff King
2022-07-08 21:47                       ` Ævar Arnfjörð Bjarmason
2022-07-11  9:33                         ` Jeff King
2022-07-08 14:20                   ` [PATCH 7/7] xdiff: remove xdl_free(), use free() instead Ævar Arnfjörð Bjarmason
2022-07-08 17:51                     ` Phillip Wood
2022-07-08 21:26                       ` Ævar Arnfjörð Bjarmason
2022-07-11  9:26                         ` Phillip Wood
2022-07-11  9:54                           ` Phillip Wood
2022-07-11 10:02                           ` Ævar Arnfjörð Bjarmason
2022-07-13 13:00                             ` Phillip Wood
2022-07-13 13:18                               ` Ævar Arnfjörð Bjarmason
2022-06-30 18:32   ` [PATCH 3/3] xdiff: introduce XDL_ALLOC_GROW() Junio C Hamano
2022-07-06 13:14     ` Phillip Wood
2022-06-30 10:46 ` [PATCH 0/3] xdiff: introduce memory allocation macros Ævar Arnfjörð Bjarmason
2022-07-08 16:25 ` [PATCH v2 0/4] " Phillip Wood via GitGitGadget
2022-07-08 16:25   ` [PATCH v2 1/4] xdiff: introduce XDL_ALLOC_ARRAY() Phillip Wood via GitGitGadget
2022-07-08 16:25   ` [PATCH v2 2/4] xdiff: introduce xdl_calloc Phillip Wood via GitGitGadget
2022-07-08 16:25   ` [PATCH v2 3/4] xdiff: introduce XDL_CALLOC_ARRAY() Phillip Wood via GitGitGadget
2022-07-08 16:25   ` [PATCH v2 4/4] xdiff: introduce XDL_ALLOC_GROW() Phillip Wood via GitGitGadget
2022-07-08 22:17     ` Ævar Arnfjörð Bjarmason
2022-07-11 10:00       ` Phillip Wood
2022-07-12  7:19         ` Jeff King
2022-07-13  9:38           ` Phillip Wood [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=46f70aff-59f1-01ca-8f1f-b07b230011bc@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.