git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Ronan Pigott <ronan@rjp.ie>
Subject: Re: [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement
Date: Tue, 15 Nov 2022 17:05:32 +0100	[thread overview]
Message-ID: <221115.86v8ngjj72.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <r31o6p7q-po67-osr1-3qq8-93s4p3o23nq2@tzk.qr>


On Tue, Nov 15 2022, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Tue, 15 Nov 2022, Johannes Schindelin wrote:
>
>> On Tue, 15 Nov 2022, Ævar Arnfjörð Bjarmason wrote:
>>
>> > In 1f80129d61b (maintenance: add option to register in a specific
>> > config, 2022-11-09) code was added which triggers a
>> > "-Wdeclaration-after-statement" warning, which is on by default with
>> > DEVELOPER=1.
>> >
>> > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> > ---
>> >
>> > This landed in the latest "next" push-out, causing e.g this CI
>> > failure:
>> > https://github.com/git/git/actions/runs/3467538041/jobs/5792504315
>>
>> I looked at the same thing all morning, and found that
>> https://lore.kernel.org/git/20221111231910.26769-1-ronan@rjp.ie/
>> _probably_ was designed to fix the same issue (and I think you agree that
>> that patch should be used instead of yours because it is more complete in
>> fixing left-over issues).
>>
>> However, try as I might, I did not find out yet why it does not apply
>> cleanly over here (I got side-tracked into range-diff'ing patches
>> downloaded from the archive, which is quite the challenge and not even fun
>> because `range-diff` requires commits, not emails, so I side-tracked
>> myself into teaching `range-diff` to accept mbox arguments).
>>
>> Maybe you can adjust that patch so it applies cleanly?
>
> Seems that the v2 of "maintenance: improve error reporting for
> unregister" [*1*] was _partially_ folded into v3 of "maintenance: add
> option to register in a specific config": At least the config change that
> talks about `--config-file` inste of `--config` _is_ part of v3, and one
> reason that the former patch does not apply cleanly on top of the latter
> patch. Which is a bit funny because the former patch was sent out two days
> _after_ the latter patch.
>
> And it looks as if there is one more thing that needs to be forward-ported
> from that no-longer-applying patch: the initialization of the configset,
> otherwise we're potentially trying to clear an uninitialized data
> structure.
>
> This is the patch I am currently testing (on top of Git for Windows'
> `shears/seen` branch:
> https://github.com/git-for-windows/git/commit/cd7b86d19f):
>
> -- snip --
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 635f12499d68..a3f63880dfba 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -1569,6 +1569,7 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi
>  	int found = 0;
>  	struct string_list_item *item;
>  	const struct string_list *list;
> +	struct config_set cs;
>
>  	argc = parse_options(argc, argv, prefix, options,
>  			     builtin_maintenance_unregister_usage, 0);
> @@ -1576,9 +1577,8 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi
>  		usage_with_options(builtin_maintenance_unregister_usage,
>  				   options);
>
> -	struct config_set cs;
> +	git_configset_init(&cs);
>  	if (config_file) {
> -		git_configset_init(&cs);
>  		git_configset_add_file(&cs, config_file);
>  		list = git_configset_get_value_multi(&cs, key);
>  	} else {
> -- snap --
>
> Ævar, can you please have a thorough look and see whether there is
> anything else we were missing before advancing this to `next`?

Thanks, I submitted a v2 just now that addresses the unit'd issue as
well, and as we're fixing that we can just reduce the scope of the
variable, which makes it lifetime more obvious:

https://lore.kernel.org/git/patch-v2-1.1-f37e99c9d59-20221115T160240Z-avarab@gmail.com/

  reply	other threads:[~2022-11-15 16:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15  8:04 [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement Ævar Arnfjörð Bjarmason
2022-11-15  9:37 ` Johannes Schindelin
2022-11-15  9:54   ` Johannes Schindelin
2022-11-15 16:05     ` Ævar Arnfjörð Bjarmason [this message]
2022-11-15 16:04 ` [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Ævar Arnfjörð Bjarmason
2022-11-15 17:34   ` Taylor Blau
2022-11-15 16:32 ` ronan
2022-11-15 17:35   ` Taylor Blau
2022-11-15 18:00   ` ronan
2022-11-15 18:54     ` Taylor Blau

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=221115.86v8ngjj72.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.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 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).