From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Derrick Stolee <derrickstolee@github.com>,
Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Ronan Pigott <ronan@rjp.ie>,
Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH] builtin/gc.c: fix use-after-free in maintenance_unregister()
Date: Wed, 16 Nov 2022 15:14:11 -0500 [thread overview]
Message-ID: <Y3VEk5VbAow0bqpS@nand.local> (raw)
In-Reply-To: <221116.865yffj5ha.gmgdl@evledraar.gmail.com>
On Wed, Nov 16, 2022 at 04:14:30PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> Copying from other zero-initializations of `struct config_set`:
> >>
> >> $ git grep -oh 'struct config_set.*= {.*' | sort | uniq -c
> >> 3 struct config_set cs = { { 0 } };
> >
> > Yes, without the double braces the compiler will complain on
> > macOS, I believe.
>
> Ah, that was sorted in 54795d37d9e (config.mak.dev: disable suggest
> braces error on old clang versions, 2022-10-10).
>
> It's fine here, we can follow-up for the #leftoverbits of changing those
> some other time.
Thanks for the reference to 54795d37d9e, Ævar.
There are a small handful of these sitting around in our codebase:
$ git grep '{ { '
builtin/gc.c: struct config_set cs = { { 0 } };
builtin/worktree.c: struct config_set cs = { { 0 } };
oidmap.h:#define OIDMAP_INIT { { NULL } }
oidset.h:#define OIDSET_INIT { { 0 } }
reftable/stack_test.c: struct reftable_ref_record refs[2] = { { NULL } };
reftable/stack_test.c: struct reftable_log_record logs[2] = { { NULL } };
reftable/stack_test.c: struct reftable_ref_record refs[2] = { { NULL } };
reftable/stack_test.c: struct reftable_log_record logs[2] = { { NULL } };
reftable/stack_test.c: struct reftable_log_record logs[20] = { { NULL } };
reset.c: struct tree_desc desc[2] = { { NULL }, { NULL } };
t/helper/test-ref-store.c:static struct flag_definition empty_flags[] = { { NULL, 0 } };
worktree.c: struct config_set cs = { { 0 } };
But I tend to agree that I'm not all that eager to go and change these
for the sake of changing them. I think we can slowly let them age out of
the codebase when we're touching nearby areas in the future.
Thanks,
Taylor
prev parent reply other threads:[~2022-11-16 20:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 18:53 [PATCH] builtin/gc.c: fix use-after-free in maintenance_unregister() Taylor Blau
2022-11-15 19:00 ` Derrick Stolee
2022-11-15 19:51 ` Ævar Arnfjörð Bjarmason
2022-11-15 19:41 ` Ævar Arnfjörð Bjarmason
2022-11-15 19:54 ` Taylor Blau
2022-11-16 13:44 ` Derrick Stolee
2022-11-16 15:14 ` Ævar Arnfjörð Bjarmason
2022-11-16 20:14 ` Taylor Blau [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=Y3VEk5VbAow0bqpS@nand.local \
--to=me@ttaylorr.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=jeffhost@microsoft.com \
--cc=ronan@rjp.ie \
/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.