From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: Eric Wong <e@80x24.org>, git@vger.kernel.org
Subject: Re: [PATCH] commit-reach: avoid NULL dereference
Date: Mon, 13 Feb 2023 09:29:05 -0800 [thread overview]
Message-ID: <xmqqmt5hcw4e.fsf@gitster.g> (raw)
In-Reply-To: <876cf920-113a-90cf-f49e-6e1b7b146acf@github.com> (Derrick Stolee's message of "Mon, 13 Feb 2023 08:58:46 -0500")
Derrick Stolee <derrickstolee@github.com> writes:
>> The above seems to indicate that the expectation by callers is a bit
>> uneven. Shouldn't the first onetrust the callee to clear the flag?
>
> Yes, that makes sense. (But there's more!)
> ...
> Thanks for digging into the details here. I agree that this extra
> assignment of the flag to these non-commit objects is unnecessary
> since we intend to clear them by the end of the method and don't
> do anything with the flags otherwise.
>
> What you seem to be suggesting is this diff:
>
> diff --git a/commit-reach.c b/commit-reach.c
> index 2e33c599a82..8c387911228 100644
> --- a/commit-reach.c
> +++ b/commit-reach.c
> @@ -740,10 +740,8 @@ int can_all_from_reach_with_flag(struct object_array *from,
> /*
> * no way to tell if this is reachable by
> * looking at the ancestry chain alone, so
> - * leave a note to ourselves not to worry about
> - * this object anymore.
> + * skip it.
> */
> - from->objects[i].item->flags |= assign_flag;
> continue;
> }
Agreed with this part.
> @@ -856,17 +854,6 @@ int can_all_from_reach(struct commit_list *from, struct commit_list *to,
>
> result = can_all_from_reach_with_flag(&from_objs, PARENT2, PARENT1,
> min_commit_date, min_generation);
> -
> - while (from) {
> - clear_commit_marks(from->item, PARENT1);
> - from = from->next;
> - }
This too.
> - while (to) {
> - clear_commit_marks(to->item, PARENT2);
> - to = to->next;
> - }
But I didn't think this is redundant. PARENT2 is used to mark "to"
commits by this function, not the callee, before making the call.
The callee may clear PARENT1 used to mark the ones visited by the
traversal starting from the "from" commits, but does not do anything
to "with_flag", does it?
> object_array_clear(&from_objs);
> return result;
> }
>
> And instead of the current patch, this should allow the
> following diff hunk instead:
>
> @@ -807,9 +805,6 @@ int can_all_from_reach_with_flag(struct object_array *from,
> clear_commit_marks_many(nr_commits, list, RESULT | assign_flag);
> free(list);
>
> - for (i = 0; i < from->nr; i++)
> - from->objects[i].item->flags &= ~assign_flag;
> -
> return result;
> }
>
> This avoids the need for the NULL check, since we are skipping the
> entire loop. The clear_commit_marks_many() is sufficient.
Yeah, that was my reading based on very limited and sufrace level of
understanding of what this function was doing, although I think my
understanding of it is still very skimpy (if I understand it well
enough, I would give it a bit more understandable name but I cannot
come up with one yet).
Thanks.
prev parent reply other threads:[~2023-02-13 17:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 11:15 [PATCH] commit-reach: avoid NULL dereference Eric Wong
2023-02-11 22:43 ` Junio C Hamano
2023-02-13 13:58 ` Derrick Stolee
2023-02-13 17:29 ` Junio C Hamano [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=xmqqmt5hcw4e.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=derrickstolee@github.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
/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 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 NNTP newsgroup(s).