Re: [PATCH 02/10] merge-recursive.c: call a new unpack_trees_options_init() function
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Oct 4, 2021, 14:41 UTC
- Message-ID
- <87y278n8tt.fsf@evledraar.gmail.com>
- In-Reply-To
- <CABPp-BFYxWXZQXvDSrM1Y1ZaQ1d2TENQDvx1cyawvrDO1OvExA@mail.gmail.com>
On Mon, Oct 04 2021, Elijah Newren wrote:
Show 13 quoted lines
> On Sun, Oct 3, 2021 at 5:46 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: >> >> In the preceding commit we introduced a new UNPACK_TREES_OPTIONS_INIT >> macro, but "merge-recursive.c" could not be converted to it since >> it (re-)initializes a "struct unpack_trees_options" on the heap. >> >> In order to convert use the macro as the source of truth for >> initialization we need to not only convert the initialization in >> unpack_trees_start(), but also call the new >> unpack_trees_options_init() just after the CALLOC_ARRAY() in >> merge_start(). > > Um...why?
Replied below.
Show 20 quoted lines
>> When we call merge_trees() we'll call merge_start() followed by >> merge_trees_internal(), and it will call unpack_trees_start() before >> it does much of anything. So it's covered by an initialization in >> unpack_trees_start(). >> >> But when merge_recursive() is called it will call merge_start() >> followed by merge_recursive_internal(), which won't call >> unpack_trees_start() until its own call call to >> merge_trees_internal(), but in the meantime it might end up using that >> calloc'd "struct unpack_trees_options". > > Nothing in merge-recursive.c usings unpack_opts before > unpack_trees_start() or after unpack_trees_finish(). If anyone > attempts to use it elsewhere, that would itself be a bug. So, I'd > replace the above three paragraphs with: > > "Change the initialization of opt->priv_unpack_opts from using memset > to 0, with unpack_trees_options_init()." > > or something like that, and then drop your change to merge_start().
Sure, I'll defer to you about being confident about that. I didn't want to leave a copy if it hanging without the proper initialization in case there were new callers.
Show 13 quoted lines
>> This was OK before, as setup_unpack_trees_porcelain() would call >> strvec_init(), and our "struct dir_struct" in turn is OK with being >> NULL'd. Let's convert the former to macro initialization, we'll deal >> with the latter in a subsequent commit. > > This is quite confusing; it's really hard to understand how this > relates to the rest of the commit message. I have to read the code to > see what you're doing, and then write my own commit message in my head > because the wording in this paragraph still doesn't parse. > > I'd make the change strvec_init/STRVEC_INIT changes be a separate > patch. I suspect it'll be easier to write the commit message for it > as a standalone commit as well.
Sure, FWIW I had it split up locally, and figured it would be easier to explain if the API usage change came with the initialization change that made it possible.
Show 28 quoted lines
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>> merge-recursive.c | 3 ++-
>> unpack-trees.c | 8 ++++++--
>> unpack-trees.h | 5 ++++-
>> 3 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/merge-recursive.c b/merge-recursive.c
>> index e594d4c3fa1..d24a4903f1d 100644
>> --- a/merge-recursive.c
>> +++ b/merge-recursive.c
>> @@ -405,7 +405,7 @@ static int unpack_trees_start(struct merge_options *opt,
>> struct tree_desc t[3];
>> struct index_state tmp_index = { NULL };
>>
>> - memset(&opt->priv->unpack_opts, 0, sizeof(opt->priv->unpack_opts));
>> + unpack_trees_options_init(&opt->priv->unpack_opts);
>> if (opt->priv->call_depth)
>> opt->priv->unpack_opts.index_only = 1;
>> else
>> @@ -3704,6 +3704,7 @@ static int merge_start(struct merge_options *opt, struct tree *head)
>>
>> CALLOC_ARRAY(opt->priv, 1);
>> string_list_init_dup(&opt->priv->df_conflict_file_set);
>> + unpack_trees_options_init(&opt->priv->unpack_opts);
>
> Drop this hunk.Speaking of splitting things up in more understandable ways: If we're going to hard rely on the interaction between merge_start() and unpack_trees_start() wouldn't it make sense to lead with a change that dropped that memset, which if this invariant holds is also redundant to the CALLOC() of opt->priv in merge_start() in the pre-image.