{"thread":{"id":"63905","subject":"[PATCH] fix -Wmaybe-uninitialized with -Og","startedAt":"2025-08-04T10:07:19Z","lastAt":"2025-08-11T09:00:09Z","messageCount":10,"participants":["Denton Liu","Jeff King","Junio C Hamano","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"523432","messageId":"d03308e9474f5e26fd4a5494ec243a278e971443.1754302009.git.liu.denton@gmail.com","threadId":"63905","inReplyTo":null,"subject":"[PATCH] fix -Wmaybe-uninitialized with -Og","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2025-08-04T10:07:15Z","receivedAt":"2025-08-04T10:07:19Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"When building with -Og on gcc 15.1.1, the build produces two warnings.\nEven though in practice, these codepaths can't actually be hit while the\nvariables are uninitialized, satisfy the compiler by initializing the\nvariables.\n\nThis also acts as defensive programming since these codepaths are a\nlittle bit spaghetti. If someone in the future makes a mistake and\ncauses the branch with the uninitialized variable to be hit, at least we\nwon't experience undefined behaviour.\n\nSigned-off-by: Denton Liu \n---\n builtin/remote.c | 2 +-\n t/unit-tests/clar/clar.c | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5dd6cbbaee..cc462677e1 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1463,7 +1463,7 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t\tb_local_head = STRBUF_INIT;\n \tchar *head_name = NULL;\n \tstruct ref_store *refs = get_main_ref_store(the_repository);\n-\tstruct remote *remote;\n+\tstruct remote *remote = NULL;\n \n \tstruct option options[] = {\n \t\tOPT_BOOL('a', \"auto\", &opt_a,\ndiff --git a/t/unit-tests/clar/clar.c b/t/unit-tests/clar/clar.c\nindex d54e455367..03a3aa8e87 100644\n--- a/t/unit-tests/clar/clar.c\n+++ b/t/unit-tests/clar/clar.c\n@@ -350,7 +350,7 @@ static void\n clar_run_suite(const struct clar_suite *suite, const char *filter)\n {\n \tconst struct clar_func *test = suite->tests;\n-\tsize_t i, matchlen;\n+\tsize_t i, matchlen = 0;\n \tstruct clar_report *report;\n \tint exact = 0;\n \n-- \n2.50.1\n\n"},{"id":"523438","messageId":"20250804131922.GB86602@coredump.intra.peff.net","threadId":"63905","inReplyTo":"d03308e9474f5e26fd4a5494ec243a278e971443.1754302009.git.liu.denton@gmail.com","subject":"Re: [PATCH] fix -Wmaybe-uninitialized with -Og","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-08-04T13:19:22Z","receivedAt":"2025-08-04T13:19:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 04, 2025 at 03:07:15AM -0700, Denton Liu wrote:\n\n> When building with -Og on gcc 15.1.1, the build produces two warnings.\n> Even though in practice, these codepaths can't actually be hit while the\n> variables are uninitialized, satisfy the compiler by initializing the\n> variables.\n\nI see these on gcc 14.2.0, too.\n\n> diff --git a/builtin/remote.c b/builtin/remote.c\n> index 5dd6cbbaee..cc462677e1 100644\n> --- a/builtin/remote.c\n> +++ b/builtin/remote.c\n> @@ -1463,7 +1463,7 @@ static int set_head(int argc, const char **argv, const char *prefix,\n> \t\tb_local_head = STRBUF_INIT;\n> \tchar *head_name = NULL;\n> \tstruct ref_store *refs = get_main_ref_store(the_repository);\n> -\tstruct remote *remote;\n> +\tstruct remote *remote = NULL;\n> \n> \tstruct option options[] = {\n> \t\tOPT_BOOL('a', \"auto\", &opt_a,\n\nI think you're right that this can't be triggered, but maybe a bit of\nreordering would make that more obvious both to the compiler and to\nhumans. The issue is that we do this:\n\n if (argc) {\n strbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n remote = remote_get(argv[0]);\n }\n\nand then follow it up with various sanity checks about how the value of\nargc. But we always require that argc is at least 1 or we bail with a\nusage message.\n\nThis comes from 012bc566ba (remote set-head: set followRemoteHEAD to\n\"warn\" if \"always\", 2024-12-05). If we revert out that change and\ninstead add it later, like so:\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5dd6cbbaee..8ba02d1854 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1474,10 +1474,8 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t};\n \targc = parse_options(argc, argv, prefix, options,\n \t\t\t builtin_remote_sethead_usage, 0);\n-\tif (argc) {\n+\tif (argc)\n \t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n-\t\tremote = remote_get(argv[0]);\n-\t}\n \n \tif (!opt_a && !opt_d && argc == 2) {\n \t\thead_name = xstrdup(argv[1]);\n@@ -1501,6 +1499,8 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t} else\n \t\tusage_with_options(builtin_remote_sethead_usage, options);\n \n+\tremote = remote_get(argv[0]);\n+\n \tif (!head_name)\n \t\tgoto cleanup;\n \tstrbuf_addf(&b_remote_head, \"refs/remotes/%s/%s\", argv[0], head_name);\n\nthen the compiler is happy. Though I still find the whole b_head thing\nto be total spaghetti (it must be set before our argc if/else cascade\nbecause deletion mode expects it there, but we can't just set it inside\nthere because other modes expect it to be set later on).\n\nSo I wonder if this would be much more obvious (again, to both humans\nand compilers):\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5dd6cbbaee..f0e49a5681 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1474,10 +1474,13 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t};\n \targc = parse_options(argc, argv, prefix, options,\n \t\t\t builtin_remote_sethead_usage, 0);\n-\tif (argc) {\n-\t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n-\t\tremote = remote_get(argv[0]);\n-\t}\n+\n+\t/* All modes require at least a remote name. */\n+\tif (!argc)\n+\t\tusage_with_options(builtin_remote_sethead_usage, options);\n+\n+\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n+\tremote = remote_get(argv[0]);\n \n \tif (!opt_a && !opt_d && argc == 2) {\n \t\thead_name = xstrdup(argv[1]);\n\n> diff --git a/t/unit-tests/clar/clar.c b/t/unit-tests/clar/clar.c\n> index d54e455367..03a3aa8e87 100644\n> --- a/t/unit-tests/clar/clar.c\n> +++ b/t/unit-tests/clar/clar.c\n> @@ -350,7 +350,7 @@ static void\n> clar_run_suite(const struct clar_suite *suite, const char *filter)\n> {\n> \tconst struct clar_func *test = suite->tests;\n> -\tsize_t i, matchlen;\n> +\tsize_t i, matchlen = 0;\n> \tstruct clar_report *report;\n> \tint exact = 0;\n\nFor this one I don't see any real alternative. We set matchlen if and\nonly if \"filter\" is set:\n\n if (filter) {\n\t...\n\tmatchlen = strlen(filter);\n\t...\n }\n\nand the line it complains about is:\n\n if (filter && strncmp(test[i].name, filter, matchlen))\n\nso the short-circuit protects us. So it's only a problem if \"filter\"\nchanges between those two lines. It is in a loop, but I don't see how\n\"filter\" could ever be changed within the loop. So I'm not sure if this\nis just a compiler bug, or if there's some really subtle alias thing\nwhere filter _could_ be changed in a sub-function or something.\n\nAt any rate I agree that \"0\" is the appropriate value here, and\nassigning it to shut up the compiler is the best approach.\n\n-Peff\n"},{"id":"523440","messageId":"xmqqms8f9p2t.fsf@gitster.g","threadId":"63905","inReplyTo":"20250804131922.GB86602@coredump.intra.peff.net","subject":"Re: [PATCH] fix -Wmaybe-uninitialized with -Og","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-04T13:46:50Z","receivedAt":"2025-08-04T13:46:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So I wonder if this would be much more obvious (again, to both humans\n> and compilers):\n>\n> diff --git a/builtin/remote.c b/builtin/remote.c\n> index 5dd6cbbaee..f0e49a5681 100644\n> --- a/builtin/remote.c\n> +++ b/builtin/remote.c\n> @@ -1474,10 +1474,13 @@ static int set_head(int argc, const char **argv, const char *prefix,\n> \t};\n> \targc = parse_options(argc, argv, prefix, options,\n> \t\t\t builtin_remote_sethead_usage, 0);\n> -\tif (argc) {\n> -\t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n> -\t\tremote = remote_get(argv[0]);\n> -\t}\n> +\n> +\t/* All modes require at least a remote name. */\n> +\tif (!argc)\n> +\t\tusage_with_options(builtin_remote_sethead_usage, options);\n> +\n> +\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n> +\tremote = remote_get(argv[0]);\n\nI do not know about compilers, but a sample of one, to this human it\nis more obvious ;-).\n\n> and the line it complains about is:\n>\n> if (filter && strncmp(test[i].name, filter, matchlen))\n> ...\n> At any rate I agree that \"0\" is the appropriate value here, and\n> assigning it to shut up the compiler is the best approach.\n\n... simply because we know the value in matchlen does not matter\nwhen filter is NULL? I think that would work and I would be happy\nwith a less noisy compilation.\n\nBut any other value like 99 would equally well work, which is a bit\ndisturbing ;-).\n\nThanks.\n"},{"id":"523457","messageId":"20250804155329.GD109984@coredump.intra.peff.net","threadId":"63905","inReplyTo":"xmqqms8f9p2t.fsf@gitster.g","subject":"Re: [PATCH] fix -Wmaybe-uninitialized with -Og","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-08-04T15:53:29Z","receivedAt":"2025-08-04T15:53:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 04, 2025 at 06:46:50AM -0700, Junio C Hamano wrote:\n\n> > +\t/* All modes require at least a remote name. */\n> > +\tif (!argc)\n> > +\t\tusage_with_options(builtin_remote_sethead_usage, options);\n> > +\n> > +\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n> > +\tremote = remote_get(argv[0]);\n> \n> I do not know about compilers, but a sample of one, to this human it\n> is more obvious ;-).\n\nOK, cleaned up patch is below. Hopefully I am not stealing Denton's\nthunder, but this seemed trivial enough that I wanted to get it off my\nplate and never think of it again. ;)\n\n> > and the line it complains about is:\n> >\n> > if (filter && strncmp(test[i].name, filter, matchlen))\n> > ...\n> > At any rate I agree that \"0\" is the appropriate value here, and\n> > assigning it to shut up the compiler is the best approach.\n> \n> ... simply because we know the value in matchlen does not matter\n> when filter is NULL? I think that would work and I would be happy\n> with a less noisy compilation.\n> \n> But any other value like 99 would equally well work, which is a bit\n> disturbing ;-).\n\nIt's true that any value would work with the current code. But I think\n\"0\" makes the most sense because it is counting bytes in \"filter\". If\n\"filter\" is NULL, then we have zero matched bytes. So if anybody _did_\nlook at it, they'd hopefully do the right thing.\n\nBTW, this clar code comes from libgit2. They may want to fix it\nupstream, too. +cc Patrick.\n\n-- >8 --\nSubject: [PATCH] remote: bail early from set_head() if missing remote name\n\nIn \"git remote set-head\", we can take varying numbers of arguments\ndepending on whether we saw the \"-d\" or \"-a\" options. But the first\nargument is always the remote name.\n\nThe current code is somewhat awkward in that it conditionally handles\nthe remote name up-front like this:\n\n if (argc)\n remote = ...from argv[0]...\n\nand then only later decides to bail if we do not have the right number\nof arguments for the options we saw.\n\nThis makes it hard to figure out if \"remote\" is always set when it needs\nto be. Both for humans, but also for compilers; with -Og, gcc complains\nthat \"remote\" can be accessed without being initialized (although this\nis not true, as we'd always die with a usage message in that case).\n\nLet's instead enforce the presence of the remote argument up front,\nwhich fixes the compiler warning and is easier to understand. It does\nmean duplicating the code to print a usage message, but it's a single\nline.\n\nNoticed-by: Denton Liu \nSigned-off-by: Jeff King \n---\n builtin/remote.c | 11 +++++++----\n 1 file changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5dd6cbbaee..f0e49a5681 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1474,10 +1474,13 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t};\n \targc = parse_options(argc, argv, prefix, options,\n \t\t\t builtin_remote_sethead_usage, 0);\n-\tif (argc) {\n-\t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n-\t\tremote = remote_get(argv[0]);\n-\t}\n+\n+\t/* All modes require at least a remote name. */\n+\tif (!argc)\n+\t\tusage_with_options(builtin_remote_sethead_usage, options);\n+\n+\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n+\tremote = remote_get(argv[0]);\n \n \tif (!opt_a && !opt_d && argc == 2) {\n \t\thead_name = xstrdup(argv[1]);\n-- \n2.50.1.786.g492fc26cdf\n\n"},{"id":"523506","messageId":"cover.1754371649.git.liu.denton@gmail.com","threadId":"63905","inReplyTo":"d03308e9474f5e26fd4a5494ec243a278e971443.1754302009.git.liu.denton@gmail.com","subject":"[PATCH v2 0/2] fix -Wmaybe-uninitialized with -Og","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2025-08-05T05:31:09Z","receivedAt":"2025-08-05T05:31:13Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"When compiled with -Og, the build emits -Wmaybe-uninitialized. Fix\nthese.\n\nDenton Liu (1):\n t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og\n\nJeff King (1):\n remote: bail early from set_head() if missing remote name\n\n builtin/remote.c | 11 +++++++----\n t/unit-tests/clar/clar.c | 2 +-\n 2 files changed, 8 insertions(+), 5 deletions(-)\n\nRange-diff against v1:\n1: d03308e947 ! 1: 458ec588b7 fix -Wmaybe-uninitialized with -Og\n @@\n ## Metadata ##\n -Author: Denton Liu \n +Author: Jeff King \n \n ## Commit message ##\n - fix -Wmaybe-uninitialized with -Og\n + remote: bail early from set_head() if missing remote name\n \n - When building with -Og on gcc 15.1.1, the build produces two warnings.\n - Even though in practice, these codepaths can't actually be hit while the\n - variables are uninitialized, satisfy the compiler by initializing the\n - variables.\n + In \"git remote set-head\", we can take varying numbers of arguments\n + depending on whether we saw the \"-d\" or \"-a\" options. But the first\n + argument is always the remote name.\n \n - This also acts as defensive programming since these codepaths are a\n - little bit spaghetti. If someone in the future makes a mistake and\n - causes the branch with the uninitialized variable to be hit, at least we\n - won't experience undefined behaviour.\n + The current code is somewhat awkward in that it conditionally handles\n + the remote name up-front like this:\n +\n + if (argc)\n + remote = ...from argv[0]...\n +\n + and then only later decides to bail if we do not have the right number\n + of arguments for the options we saw.\n +\n + This makes it hard to figure out if \"remote\" is always set when it needs\n + to be. Both for humans, but also for compilers; with -Og, gcc complains\n + that \"remote\" can be accessed without being initialized (although this\n + is not true, as we'd always die with a usage message in that case).\n +\n + Let's instead enforce the presence of the remote argument up front,\n + which fixes the compiler warning and is easier to understand. It does\n + mean duplicating the code to print a usage message, but it's a single\n + line.\n +\n + Noticed-by: Denton Liu \n + Signed-off-by: Jeff King \n \n ## builtin/remote.c ##\n @@ builtin/remote.c: static int set_head(int argc, const char **argv, const char *prefix,\n - \t\tb_local_head = STRBUF_INIT;\n - \tchar *head_name = NULL;\n - \tstruct ref_store *refs = get_main_ref_store(the_repository);\n --\tstruct remote *remote;\n -+\tstruct remote *remote = NULL;\n - \n - \tstruct option options[] = {\n - \t\tOPT_BOOL('a', \"auto\", &opt_a,\n -\n - ## t/unit-tests/clar/clar.c ##\n -@@ t/unit-tests/clar/clar.c: static void\n - clar_run_suite(const struct clar_suite *suite, const char *filter)\n - {\n - \tconst struct clar_func *test = suite->tests;\n --\tsize_t i, matchlen;\n -+\tsize_t i, matchlen = 0;\n - \tstruct clar_report *report;\n - \tint exact = 0;\n + \t};\n + \targc = parse_options(argc, argv, prefix, options,\n + \t\t\t builtin_remote_sethead_usage, 0);\n +-\tif (argc) {\n +-\t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n +-\t\tremote = remote_get(argv[0]);\n +-\t}\n ++\n ++\t/* All modes require at least a remote name. */\n ++\tif (!argc)\n ++\t\tusage_with_options(builtin_remote_sethead_usage, options);\n ++\n ++\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n ++\tremote = remote_get(argv[0]);\n \n + \tif (!opt_a && !opt_d && argc == 2) {\n + \t\thead_name = xstrdup(argv[1]);\n-: ---------- > 2: 8ed0ac1409 t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og\n-- \n2.50.1\n\n"},{"id":"523507","messageId":"458ec588b7fe4d40f834d535b8f7d83684f9935b.1754371650.git.liu.denton@gmail.com","threadId":"63905","inReplyTo":"cover.1754371649.git.liu.denton@gmail.com","subject":"[PATCH v2 1/2] remote: bail early from set_head() if missing remote name","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2025-08-05T05:31:13Z","receivedAt":"2025-08-05T05:31:16Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"From: Jeff King \n\nIn \"git remote set-head\", we can take varying numbers of arguments\ndepending on whether we saw the \"-d\" or \"-a\" options. But the first\nargument is always the remote name.\n\nThe current code is somewhat awkward in that it conditionally handles\nthe remote name up-front like this:\n\n if (argc)\n remote = ...from argv[0]...\n\nand then only later decides to bail if we do not have the right number\nof arguments for the options we saw.\n\nThis makes it hard to figure out if \"remote\" is always set when it needs\nto be. Both for humans, but also for compilers; with -Og, gcc complains\nthat \"remote\" can be accessed without being initialized (although this\nis not true, as we'd always die with a usage message in that case).\n\nLet's instead enforce the presence of the remote argument up front,\nwhich fixes the compiler warning and is easier to understand. It does\nmean duplicating the code to print a usage message, but it's a single\nline.\n\nNoticed-by: Denton Liu \nSigned-off-by: Jeff King \nTested-by: Denton Liu \nSigned-off-by: Denton Liu \n---\nThanks Peff for writing this patch up\n\n builtin/remote.c | 11 +++++++----\n 1 file changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5dd6cbbaee..f0e49a5681 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1474,10 +1474,13 @@ static int set_head(int argc, const char **argv, const char *prefix,\n \t};\n \targc = parse_options(argc, argv, prefix, options,\n \t\t\t builtin_remote_sethead_usage, 0);\n-\tif (argc) {\n-\t\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n-\t\tremote = remote_get(argv[0]);\n-\t}\n+\n+\t/* All modes require at least a remote name. */\n+\tif (!argc)\n+\t\tusage_with_options(builtin_remote_sethead_usage, options);\n+\n+\tstrbuf_addf(&b_head, \"refs/remotes/%s/HEAD\", argv[0]);\n+\tremote = remote_get(argv[0]);\n \n \tif (!opt_a && !opt_d && argc == 2) {\n \t\thead_name = xstrdup(argv[1]);\n-- \n2.50.1\n\n"},{"id":"523508","messageId":"8ed0ac14092e7ec979e53d2a3da84dfe884d6b3f.1754371650.git.liu.denton@gmail.com","threadId":"63905","inReplyTo":"cover.1754371649.git.liu.denton@gmail.com","subject":"[PATCH v2 2/2] t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2025-08-05T05:31:16Z","receivedAt":"2025-08-05T05:31:19Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"When building with -Og on gcc 15.1.1, the build produces a warning. In\npractice, though, this cannot be hit because `exact` acts as a guard and\nthat variable can only be set after `matchlen` is already initialized\n\nAssign a default value to `matchlen` so that the warning is silenced.\n\nSigned-off-by: Denton Liu \n---\n t/unit-tests/clar/clar.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/unit-tests/clar/clar.c b/t/unit-tests/clar/clar.c\nindex d54e455367..03a3aa8e87 100644\n--- a/t/unit-tests/clar/clar.c\n+++ b/t/unit-tests/clar/clar.c\n@@ -350,7 +350,7 @@ static void\n clar_run_suite(const struct clar_suite *suite, const char *filter)\n {\n \tconst struct clar_func *test = suite->tests;\n-\tsize_t i, matchlen;\n+\tsize_t i, matchlen = 0;\n \tstruct clar_report *report;\n \tint exact = 0;\n \n-- \n2.50.1\n\n"},{"id":"523800","messageId":"aJWPmo6oGCuQvqMG@pks.im","threadId":"63905","inReplyTo":"8ed0ac14092e7ec979e53d2a3da84dfe884d6b3f.1754371650.git.liu.denton@gmail.com","subject":"Re: [PATCH v2 2/2] t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-08-08T05:48:10Z","receivedAt":"2025-08-08T05:48:17Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Aug 04, 2025 at 10:31:16PM -0700, Denton Liu wrote:\n> When building with -Og on gcc 15.1.1, the build produces a warning. In\n> practice, though, this cannot be hit because `exact` acts as a guard and\n> that variable can only be set after `matchlen` is already initialized\n> \n> Assign a default value to `matchlen` so that the warning is silenced.\n\nWould you mind creating a PR against upstream [1] so that we also have it\nover there? Thanks!\n\nPatrick\n\n[1]: https://github.com/clar-test/clar\n"},{"id":"523809","messageId":"aJWtbGGBOELZN6tp@generichostname","threadId":"63905","inReplyTo":"aJWPmo6oGCuQvqMG@pks.im","subject":"Re: [PATCH v2 2/2] t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2025-08-08T07:55:24Z","receivedAt":"2025-08-08T07:55:28Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Fri, Aug 08, 2025 at 07:48:10AM +0200, Patrick Steinhardt wrote:\n> On Mon, Aug 04, 2025 at 10:31:16PM -0700, Denton Liu wrote:\n> > When building with -Og on gcc 15.1.1, the build produces a warning. In\n> > practice, though, this cannot be hit because `exact` acts as a guard and\n> > that variable can only be set after `matchlen` is already initialized\n> > \n> > Assign a default value to `matchlen` so that the warning is silenced.\n> \n> Would you mind creating a PR against upstream [1] so that we also have it\n> over there? Thanks!\n\nGood idea. PR over at [0]\n\n-Denton\n\n[0]: https://github.com/clar-test/clar/pull/119\n"},{"id":"523916","messageId":"aJmxExJgFKxeiHDf@pks.im","threadId":"63905","inReplyTo":"aJWtbGGBOELZN6tp@generichostname","subject":"Re: [PATCH v2 2/2] t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-08-11T09:00:03Z","receivedAt":"2025-08-11T09:00:09Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Aug 08, 2025 at 12:55:24AM -0700, Denton Liu wrote:\n> On Fri, Aug 08, 2025 at 07:48:10AM +0200, Patrick Steinhardt wrote:\n> > On Mon, Aug 04, 2025 at 10:31:16PM -0700, Denton Liu wrote:\n> > > When building with -Og on gcc 15.1.1, the build produces a warning. In\n> > > practice, though, this cannot be hit because `exact` acts as a guard and\n> > > that variable can only be set after `matchlen` is already initialized\n> > > \n> > > Assign a default value to `matchlen` so that the warning is silenced.\n> > \n> > Would you mind creating a PR against upstream [1] so that we also have it\n> > over there? Thanks!\n> \n> Good idea. PR over at [0]\n> \n> -Denton\n> \n> [0]: https://github.com/clar-test/clar/pull/119\n\nThanks, approved and merged now.\n\nPatrick\n"}]}