# [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement 10 messages from 2022-11-15 to 2022-11-15. Participants: Ævar Arnfjörð Bjarmason, Johannes Schindelin, ronan@rjp.ie, Taylor Blau. Thread: https://gitlist.dev/t/58800 ## Ævar Arnfjörð Bjarmason, 2022-11-15 08:04 Subject: [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/patch-1.1-54d405f15f1-20221115T080212Z-avarab%40gmail.com ``` 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 --- This landed in the latest "next" push-out, causing e.g this CI failure: https://github.com/git/git/actions/runs/3467538041/jobs/5792504315 builtin/gc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/gc.c b/builtin/gc.c index 56b107e7f0b..22a990db0be 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -1543,6 +1543,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); @@ -1550,7 +1551,6 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi usage_with_options(builtin_maintenance_unregister_usage, options); - struct config_set cs; if (config_file) { git_configset_init(&cs); git_configset_add_file(&cs, config_file); -- 2.38.0.1473.g172bcc0511c ``` ## Johannes Schindelin, 2022-11-15 09:37 Subject: Re: [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement Message-ID: <3p6n2r7s-q136-n7q9-8o27-740q4qr5os84@tzk.qr> URL: https://gitlist.dev/e/3p6n2r7s-q136-n7q9-8o27-740q4qr5os84%40tzk.qr In-Reply-To: ``` Hi Ævar, 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 > --- > > 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? Ciao, Dscho > > builtin/gc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/gc.c b/builtin/gc.c > index 56b107e7f0b..22a990db0be 100644 > --- a/builtin/gc.c > +++ b/builtin/gc.c > @@ -1543,6 +1543,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); > @@ -1550,7 +1551,6 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi > usage_with_options(builtin_maintenance_unregister_usage, > options); > > - struct config_set cs; > if (config_file) { > git_configset_init(&cs); > git_configset_add_file(&cs, config_file); > -- > 2.38.0.1473.g172bcc0511c > > > ``` ## Johannes Schindelin, 2022-11-15 09:54 Subject: Re: [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/r31o6p7q-po67-osr1-3qq8-93s4p3o23nq2%40tzk.qr In-Reply-To: <3p6n2r7s-q136-n7q9-8o27-740q4qr5os84@tzk.qr> ``` 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 > > --- > > > > 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, Dscho Footnote *1*: https://lore.kernel.org/git/20221111231910.26769-1-ronan@rjp.ie/ Footnote *2*: https://lore.kernel.org/git/20221109190708.22725-3-ronan@rjp.ie/ ``` ## Ævar Arnfjörð Bjarmason, 2022-11-15 16:04 Subject: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/patch-v2-1.1-f37e99c9d59-20221115T160240Z-avarab%40gmail.com In-Reply-To: ``` Since (maintenance: add option to register in a specific config, 2022-11-09) we've been unable to build with "DEVELOPER=1" without "DEVOPTS=no-error", as the added code triggers a "-Wdeclaration-after-statement" warning. And worse than that, the data handed to git_configset_clear() is uninitialized, as can be spotted with e.g.: ./t7900-maintenance.sh -vixd --run=23 --valgrind [...] + git maintenance unregister --force Conditional jump or move depends on uninitialised value(s) at 0x6B5F1E: git_configset_clear (config.c:2367) by 0x4BA64E: maintenance_unregister (gc.c:1619) by 0x4BD278: cmd_maintenance (gc.c:2650) by 0x409905: run_builtin (git.c:466) by 0x40A21C: handle_builtin (git.c:721) by 0x40A58E: run_argv (git.c:788) by 0x40AF68: cmd_main (git.c:926) by 0x5D39FE: main (common-main.c:57) Uninitialised value was created by a stack allocation at 0x4BA22C: maintenance_unregister (gc.c:1557) Let's fix both of these issues, and also move the scope of the variable to the "if" statement it's used in, to make it obvious where it's used. Helped-by: Johannes Schindelin Signed-off-by: Ævar Arnfjörð Bjarmason --- Range-diff against v1: 1: 54d405f15f1 ! 1: f37e99c9d59 builtin/gc.c: fix -Wdeclaration-after-statement @@ Metadata Author: Ævar Arnfjörð Bjarmason ## Commit message ## - builtin/gc.c: fix -Wdeclaration-after-statement + maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement - 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. + Since (maintenance: add option to register in a specific config, + 2022-11-09) we've been unable to build with "DEVELOPER=1" without + "DEVOPTS=no-error", as the added code triggers a + "-Wdeclaration-after-statement" warning. + And worse than that, the data handed to git_configset_clear() is + uninitialized, as can be spotted with e.g.: + + ./t7900-maintenance.sh -vixd --run=23 --valgrind + [...] + + git maintenance unregister --force + Conditional jump or move depends on uninitialised value(s) + at 0x6B5F1E: git_configset_clear (config.c:2367) + by 0x4BA64E: maintenance_unregister (gc.c:1619) + by 0x4BD278: cmd_maintenance (gc.c:2650) + by 0x409905: run_builtin (git.c:466) + by 0x40A21C: handle_builtin (git.c:721) + by 0x40A58E: run_argv (git.c:788) + by 0x40AF68: cmd_main (git.c:926) + by 0x5D39FE: main (common-main.c:57) + Uninitialised value was created by a stack allocation + at 0x4BA22C: maintenance_unregister (gc.c:1557) + + Let's fix both of these issues, and also move the scope of the + variable to the "if" statement it's used in, to make it obvious where + it's used. + + Helped-by: Johannes Schindelin Signed-off-by: Ævar Arnfjörð Bjarmason ## builtin/gc.c ## -@@ builtin/gc.c: 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); @@ builtin/gc.c: static int maintenance_unregister(int argc, const char **argv, const char *prefi usage_with_options(builtin_maintenance_unregister_usage, options); - struct config_set cs; if (config_file) { ++ struct config_set cs; ++ git_configset_init(&cs); git_configset_add_file(&cs, config_file); + list = git_configset_get_value_multi(&cs, key); ++ git_configset_clear(&cs); + } else { + list = git_config_get_value_multi(key); + } +@@ builtin/gc.c: static int maintenance_unregister(int argc, const char **argv, const char *prefi + die(_("repository '%s' is not registered"), maintpath); + } + +- git_configset_clear(&cs); + free(maintpath); + return 0; + } builtin/gc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/builtin/gc.c b/builtin/gc.c index 56b107e7f0b..d87cf84041f 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -1550,11 +1550,13 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi usage_with_options(builtin_maintenance_unregister_usage, options); - struct config_set cs; if (config_file) { + struct config_set cs; + git_configset_init(&cs); git_configset_add_file(&cs, config_file); list = git_configset_get_value_multi(&cs, key); + git_configset_clear(&cs); } else { list = git_config_get_value_multi(key); } @@ -1590,7 +1592,6 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi die(_("repository '%s' is not registered"), maintpath); } - git_configset_clear(&cs); free(maintpath); return 0; } -- 2.38.0.1473.g172bcc0511c ``` ## Ævar Arnfjörð Bjarmason, 2022-11-15 16:05 Subject: Re: [PATCH] builtin/gc.c: fix -Wdeclaration-after-statement Message-ID: <221115.86v8ngjj72.gmgdl@evledraar.gmail.com> URL: https://gitlist.dev/e/221115.86v8ngjj72.gmgdl%40evledraar.gmail.com In-Reply-To: ``` 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 >> > --- >> > >> > 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/ ``` ## ronan@rjp.ie, 2022-11-15 16:32 Subject: Re: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: <1ab6aa0e8178c88689f26b8df9ec75cb@rjp.ie> URL: https://gitlist.dev/e/1ab6aa0e8178c88689f26b8df9ec75cb%40rjp.ie In-Reply-To: ``` November 15, 2022 9:04 AM, "Ævar Arnfjörð Bjarmason" wrote: > Since (maintenance: add option to register in a specific config, > 2022-11-09) we've been unable to build with "DEVELOPER=1" without > "DEVOPTS=no-error", as the added code triggers a > "-Wdeclaration-after-statement" warning. > > And worse than that, the data handed to git_configset_clear() is > uninitialized, as can be spotted with e.g.: Sorry, I'm a little confused. I had sent v1, v2, and v3 of the "maintenance: add option [...]" patch, but as I understand it v2 had already been applied so I was asked to resubmit the changes from v3 rebased on next. I had done that in [1], but these issues were caught in review so I submitted a v2 of that correction in [2] which declares the configsset earlier and unconditionally initializes it is cleared. Are these further issues discovered after [2] was applied, or was there some issue rebasing the patches? [1] https://lore.kernel.org/git/20221110225310.7488-1-ronan@rjp.ie/ [2] https://lore.kernel.org/git/20221111231910.26769-1-ronan@rjp.ie/ ``` ## Taylor Blau, 2022-11-15 17:34 Subject: Re: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/Y3PNolwofKgbkLh5%40nand.local In-Reply-To: ``` On Tue, Nov 15, 2022 at 05:04:27PM +0100, Ævar Arnfjörð Bjarmason wrote: > Since (maintenance: add option to register in a specific config, > 2022-11-09) we've been unable to build with "DEVELOPER=1" without > "DEVOPTS=no-error", as the added code triggers a > "-Wdeclaration-after-statement" warning. > > And worse than that, the data handed to git_configset_clear() is > uninitialized, as can be spotted with e.g.: > > ./t7900-maintenance.sh -vixd --run=23 --valgrind > [...] > + git maintenance unregister --force > Conditional jump or move depends on uninitialised value(s) > at 0x6B5F1E: git_configset_clear (config.c:2367) > by 0x4BA64E: maintenance_unregister (gc.c:1619) > by 0x4BD278: cmd_maintenance (gc.c:2650) > by 0x409905: run_builtin (git.c:466) > by 0x40A21C: handle_builtin (git.c:721) > by 0x40A58E: run_argv (git.c:788) > by 0x40AF68: cmd_main (git.c:926) > by 0x5D39FE: main (common-main.c:57) > Uninitialised value was created by a stack allocation > at 0x4BA22C: maintenance_unregister (gc.c:1557) > > Let's fix both of these issues, and also move the scope of the > variable to the "if" statement it's used in, to make it obvious where > it's used. > > Helped-by: Johannes Schindelin > Signed-off-by: Ævar Arnfjörð Bjarmason Thanks, both. I could have sworn I picked up the right version of this topic when queuing, but apparently not. I pushed this out to 'next' and rebuilt jch and seen based on the new version. The result now should be OK. Thanks again for noticing and working together. Thanks, Taylor ``` ## Taylor Blau, 2022-11-15 17:35 Subject: Re: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/Y3PN4K1ULrvGCEEE%40nand.local In-Reply-To: <1ab6aa0e8178c88689f26b8df9ec75cb@rjp.ie> ``` On Tue, Nov 15, 2022 at 04:32:03PM +0000, ronan@rjp.ie wrote: > I had done that in [1], but these issues were caught in review so I > submitted a v2 of that correction in [2] which declares the configsset > earlier and unconditionally initializes it is cleared. Are these > further issues discovered after [2] was applied, or was there some > issue rebasing the patches? > > [1] https://lore.kernel.org/git/20221110225310.7488-1-ronan@rjp.ie/ > [2] https://lore.kernel.org/git/20221111231910.26769-1-ronan@rjp.ie/ It was human error on my part. Please let me know if the result in 'next' now is OK to you. Thanks, Taylor ``` ## ronan@rjp.ie, 2022-11-15 18:00 Subject: Re: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/d66fad29eb4c80fd1e9db4cfe5077085%40rjp.ie In-Reply-To: ``` November 15, 2022 10:35 AM, "Taylor Blau" wrote: > It was human error on my part. Please let me know if the result in > 'next' now is OK to you. Had a look and I'm just wondering if we're sure it's alright to clear the configset before using the list we found in it. Doesn't that list point into the configset? ``` ## Taylor Blau, 2022-11-15 18:54 Subject: Re: [PATCH v2] maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Message-ID: URL: https://gitlist.dev/e/Y3PgdXp30kLA15E%2B%40nand.local In-Reply-To: ``` On Tue, Nov 15, 2022 at 06:00:45PM +0000, ronan@rjp.ie wrote: > November 15, 2022 10:35 AM, "Taylor Blau" wrote: > > > It was human error on my part. Please let me know if the result in > > 'next' now is OK to you. > > Had a look and I'm just wondering if we're sure it's alright to clear > the configset before using the list we found in it. Doesn't that list > point into the configset? It does. I should not have trusted the incoming patch so blindly. See: https://lore.kernel.org/git/2cbead254b77cb02d219bca8f628dc4362c045b0.1668538355.git.me@ttaylorr.com/ for a fixup on top. Thanks, Taylor ```