All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Vosmaer <jacob@gitlab.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Git Mailing List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 2/3] ls-refs.c: initialize 'prefixes' before using it
Date: Wed, 20 Jan 2021 22:50:22 +0100	[thread overview]
Message-ID: <CADMWQoNH+1MRGYsrJjHTUqhyYMHb9XP5-dQ3KHLT2qNVGGtttA@mail.gmail.com> (raw)
In-Reply-To: <5fc081b2d554db305400ec52fac8683a3ed59597.1611158549.git.me@ttaylorr.com>

As the person whose name is on the "From:" line, I approve. And thanks!

On Wed, Jan 20, 2021 at 5:04 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> From: Jacob Vosmaer <jacob@gitlab.com>
>
> Correctly initialize the "prefixes" strvec using strvec_init() instead
> of simply zeroing it via the earlier memset().
>
> There's no way to trigger a crash, since the first 'ref-prefix' command
> will initialize the strvec via the 'ALLOC_GROW' in 'strvec_push_nodup()'
> (the alloc and nr variables are already zero'd, so the call to
> ALLOC_GROW is valid).
>
> If no "ref-prefix" command was given, then the call to
> 'ls-refs.c:ref_match()' will abort early after it reads the zero in
> 'prefixes->nr'. Likewise, strvec_clear() will only call free() on the
> array, which is NULL, so we're safe there, too.
>
> But, all of this is dangerous and requires more reasoning than it would
> if we simply called 'strvec_init()', so do that.
>
> Signed-off-by: Jacob Vosmaer <jacob@gitlab.com>
> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
>  ls-refs.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ls-refs.c b/ls-refs.c
> index a1e0b473e4..367597d447 100644
> --- a/ls-refs.c
> +++ b/ls-refs.c
> @@ -90,6 +90,7 @@ int ls_refs(struct repository *r, struct strvec *keys,
>         struct ls_refs_data data;
>
>         memset(&data, 0, sizeof(data));
> +       strvec_init(&data.prefixes);
>
>         git_config(ls_refs_config, NULL);
>
> --
> 2.30.0.138.g6d7191ea01
>

  parent reply	other threads:[~2021-01-20 22:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 14:42 [PATCH 0/1] ls-refs.c: minimize number of refs visited Jacob Vosmaer
2021-01-19 14:42 ` [PATCH 1/1] " Jacob Vosmaer
2021-01-19 16:12   ` Taylor Blau
2021-01-19 17:42     ` Jacob Vosmaer
2021-01-19 18:19       ` [PATCH 0/2] ls-refs: only traverse through longest common ref prefix Taylor Blau
2021-01-19 18:19         ` [PATCH 1/2] refs: expose 'for_each_fullref_in_prefixes' Taylor Blau
2021-01-19 18:19         ` [PATCH 2/2] ls-refs.c: traverse longest common ref prefix Taylor Blau
2021-01-19 23:09           ` Jeff King
2021-01-19 23:52             ` Taylor Blau
2021-01-20  0:08               ` Jeff King
2021-01-20 11:00           ` Jacob Vosmaer
2021-01-20 16:04         ` [PATCH v2 0/3] ls-refs: traverse prefixes of disjoint "ref-prefix" sets Taylor Blau
2021-01-20 16:04           ` [PATCH v2 1/3] refs: expose 'for_each_fullref_in_prefixes' Taylor Blau
2021-01-20 19:56             ` Jeff King
2021-01-20 20:12               ` Taylor Blau
2021-01-23  2:59             ` Junio C Hamano
2021-01-25  1:35               ` Taylor Blau
2021-01-20 16:04           ` [PATCH v2 2/3] ls-refs.c: initialize 'prefixes' before using it Taylor Blau
2021-01-20 19:58             ` Jeff King
2021-01-20 20:13               ` Taylor Blau
2021-01-20 21:50             ` Jacob Vosmaer [this message]
2021-01-20 16:04           ` [PATCH v2 3/3] ls-refs.c: traverse prefixes of disjoint "ref-prefix" sets Taylor Blau
2021-01-23 17:55           ` [PATCH v2 0/3] ls-refs: " Junio C Hamano
2021-01-19 19:09       ` [PATCH 1/1] ls-refs.c: minimize number of refs visited Taylor Blau
2021-01-19 21:59         ` Jeff King
2021-01-19 22:15           ` Jeff King
2021-01-19 22:23             ` Taylor Blau
2021-01-19 22:52               ` Jeff King
2021-01-19 22:59                 ` Jeff King
2021-01-19 23:02                   ` Taylor Blau
2021-01-19 22:53   ` Jeff King
2021-01-19 23:00     ` Taylor Blau
2021-01-19 23:11       ` Jeff King
2021-01-20 10:40         ` Jacob Vosmaer
2021-01-20 10:44           ` Jacob Vosmaer

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=CADMWQoNH+1MRGYsrJjHTUqhyYMHb9XP5-dQ3KHLT2qNVGGtttA@mail.gmail.com \
    --to=jacob@gitlab.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /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.