{"thread":{"id":"63792","subject":"[PATCH] strbuf: add compound literal test balloon","startedAt":"2025-07-14T13:27:55Z","lastAt":"2025-07-26T23:15:23Z","messageCount":15,"participants":["Phillip Wood","Junio C Hamano","Patrick Steinhardt","Collin Funk"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"521897","messageId":"7ac55a5096c261b706f47ca239c381f71db2b67a.1752499653.git.phillip.wood@dunelm.org.uk","threadId":"63792","inReplyTo":null,"subject":"[PATCH] strbuf: add compound literal test balloon","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-07-14T13:27:37Z","receivedAt":"2025-07-14T13:27:55Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"From: Phillip Wood \n\nA C99 compound literal creates an unnamed object whose value is given by\nan initializer list. This allows us to simplify code where we cannot use\na designated initalizer because the values of some members of the object\nneed to be calculated first. For example this code from builtin/rebase.c\n\n\tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n\tstruct reset_head_opts ropts = { 0 };\n\tint ret;\n\n\tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n\t\t opts->reflog_action,\n\t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n\tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n\t\t opts->reflog_action, opts->head_name);\n\tropts.branch = opts->head_name;\n\tropts.flags = RESET_HEAD_REFS_ONLY;\n\tropts.branch_msg = branch_reflog.buf;\n\tropts.head_msg = head_reflog.buf;\n\tret = reset_head(the_repository, &ropts);\n\ncan be be simplified to\n\n\tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n\tint ret;\n\n\tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n\t\t opts->reflog_action,\n\t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n\tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n\t\t opts->reflog_action, opts->head_name);\n ret = reset_head(the_repository, &(struct reset_head_opts) {\n .branch = opts->head_name,\n \t.flags = RESET_HEAD_REFS_ONLY,\n \t.branch_msg = branch_reflog.buf,\n \t.head_msg = head_reflog.buf,\n });\n\nThe result is more readable as one can see the value of each member\nof the object being passed to the function at the call site rather\nthan building the object piecemeal in the preceding lines.\n\nA common pattern in our code base is to define a struct together\nwith an initializer macro to initialize automatic variables and an\ninitializer function to initialize dynamically allocated instances\nof the struct. Typically the initializer function for \"struct foo\"\nlooks like\n\n void foo_init(struct foo *f)\n {\n struct foo blank = FOO_INIT;\n memcpy(f, &blank, sizeof(*f));\n }\n\nwhich enables us to reuse the initializer macro FOO_INIT to initalize\ndynamically allocated objects. By using a compound literal we can\nsimplify this to\n\n void foo_init(struct foo *f)\n {\n *f = (struct foo) FOO_INIT;\n }\n\nLet's add a test balloon to check for compiler support by changing\nstrbuf_init() to use a compound literal in the hope of using this\nfeature more widely in the future.\n\nSigned-off-by: Phillip Wood \n---\nBase-Commit: a30f80fde927d70950b3b4d1820813480968fb0d\nPublished-As: https://github.com/phillipwood/git/releases/tag/pw%2Fcompound-literal-test-balloon%2Fv1\nView-Changes-At: https://github.com/phillipwood/git/compare/a30f80fde...7ac55a509\nFetch-It-Via: git fetch https://github.com/phillipwood/git pw/compound-literal-test-balloon/v1\n\n strbuf.c | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/strbuf.c b/strbuf.c\nindex f30fdc69843..c93c1208c93 100644\n--- a/strbuf.c\n+++ b/strbuf.c\n@@ -68,8 +68,7 @@ char strbuf_slopbuf[1];\n \n void strbuf_init(struct strbuf *sb, size_t hint)\n {\n-\tstruct strbuf blank = STRBUF_INIT;\n-\tmemcpy(sb, &blank, sizeof(*sb));\n+\t*sb = (struct strbuf) STRBUF_INIT;\n \tif (hint)\n \t\tstrbuf_grow(sb, hint);\n }\n-- \n2.49.0.897.gfad3eb7d210\n\n"},{"id":"521899","messageId":"xmqqa556x2z4.fsf@gitster.g","threadId":"63792","inReplyTo":"7ac55a5096c261b706f47ca239c381f71db2b67a.1752499653.git.phillip.wood@dunelm.org.uk","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-14T14:26:55Z","receivedAt":"2025-07-14T14:26:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> From: Phillip Wood \n>\n> A C99 compound literal creates an unnamed object whose value is given by\n> an initializer list. This allows us to simplify code where we cannot use\n> a designated initalizer because the values of some members of the object\n> need to be calculated first. For example this code from builtin/rebase.c\n>\n> \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n> \tstruct reset_head_opts ropts = { 0 };\n> \tint ret;\n>\n> \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n> \t\t opts->reflog_action,\n> \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n> \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n> \t\t opts->reflog_action, opts->head_name);\n> \tropts.branch = opts->head_name;\n> \tropts.flags = RESET_HEAD_REFS_ONLY;\n> \tropts.branch_msg = branch_reflog.buf;\n> \tropts.head_msg = head_reflog.buf;\n> \tret = reset_head(the_repository, &ropts);\n>\n> can be be simplified to\n>\n> \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n> \tint ret;\n>\n> \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n> \t\t opts->reflog_action,\n> \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n> \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n> \t\t opts->reflog_action, opts->head_name);\n> ret = reset_head(the_repository, &(struct reset_head_opts) {\n> .branch = opts->head_name,\n> \t.flags = RESET_HEAD_REFS_ONLY,\n> \t.branch_msg = branch_reflog.buf,\n> \t.head_msg = head_reflog.buf,\n> });\n>\n> The result is more readable as one can see the value of each member\n> of the object being passed to the function at the call site rather\n> than building the object piecemeal in the preceding lines.\n\nHmph, is it simpler, I have to wonder, in other words, I doubt you\nsimplified the code.\n\nOne thing the above rewrite did is to make it clear to readers that\nthe struct instance is used just once and then immediately got\ndiscarded. As long as the object that gets passed this way does not\nhold resources that need to be discarded itself (in other words,\ndoes not require a call to reset_head_opts_release()), it makes the\ncode easier to follow.\n\nBut once the struct gains members that need to be released, I am not\nsure if this construct does not make it harder to spot leaks.\nSomebody who adds a member to _release() to the struct presumably\naudits and find all places that need to call _release(), but among\nthem they find this place---now what? They need to first convert it\nto the old fashioned way and then call _release() after the\nreset_head() call returns, I guess.\n\nI am not arguing against all uses of literals---I am just\nanticipating future fallouts of encouraging overuse of this pattern,\nand preparing what we would say when somebody adds a new use to\ninappropriate places. Simple cases like the initialier should be\nfine.\n\n> strbuf.c | 3 +--\n> 1 file changed, 1 insertion(+), 2 deletions(-)\n>\n> diff --git a/strbuf.c b/strbuf.c\n> index f30fdc69843..c93c1208c93 100644\n> --- a/strbuf.c\n> +++ b/strbuf.c\n> @@ -68,8 +68,7 @@ char strbuf_slopbuf[1];\n> \n> void strbuf_init(struct strbuf *sb, size_t hint)\n> {\n> -\tstruct strbuf blank = STRBUF_INIT;\n> -\tmemcpy(sb, &blank, sizeof(*sb));\n\nWe should mark this clearly as a weather-balloon so that people do\nnot copy and paste it to elsewhere not just yet, shouldn't we? If\nit proliferates everywhere and then later we discover that some\nvintage of compiler on a platform we still care about miscompiles\nthe construct, we want to keep it simpler to revert.\n\n> +\t*sb = (struct strbuf) STRBUF_INIT;\n> \tif (hint)\n> \t\tstrbuf_grow(sb, hint);\n> }\n\nOther than that, thanks for taking an initiative.\n"},{"id":"521952","messageId":"aHYXJ7EmRQE1P5xe@pks.im","threadId":"63792","inReplyTo":"xmqqa556x2z4.fsf@gitster.g","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-07-15T08:53:59Z","receivedAt":"2025-07-15T08:54:05Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Jul 14, 2025 at 07:26:55AM -0700, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n> > From: Phillip Wood \n> >\n> > A C99 compound literal creates an unnamed object whose value is given by\n> > an initializer list. This allows us to simplify code where we cannot use\n> > a designated initalizer because the values of some members of the object\n> > need to be calculated first. For example this code from builtin/rebase.c\n> >\n> > \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n> > \tstruct reset_head_opts ropts = { 0 };\n> > \tint ret;\n> >\n> > \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n> > \t\t opts->reflog_action,\n> > \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n> > \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n> > \t\t opts->reflog_action, opts->head_name);\n> > \tropts.branch = opts->head_name;\n> > \tropts.flags = RESET_HEAD_REFS_ONLY;\n> > \tropts.branch_msg = branch_reflog.buf;\n> > \tropts.head_msg = head_reflog.buf;\n> > \tret = reset_head(the_repository, &ropts);\n> >\n> > can be be simplified to\n> >\n> > \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n> > \tint ret;\n> >\n> > \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n> > \t\t opts->reflog_action,\n> > \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n> > \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n> > \t\t opts->reflog_action, opts->head_name);\n> > ret = reset_head(the_repository, &(struct reset_head_opts) {\n> > .branch = opts->head_name,\n> > \t.flags = RESET_HEAD_REFS_ONLY,\n> > \t.branch_msg = branch_reflog.buf,\n> > \t.head_msg = head_reflog.buf,\n> > });\n> >\n> > The result is more readable as one can see the value of each member\n> > of the object being passed to the function at the call site rather\n> > than building the object piecemeal in the preceding lines.\n> \n> Hmph, is it simpler, I have to wonder, in other words, I doubt you\n> simplified the code.\n> \n> One thing the above rewrite did is to make it clear to readers that\n> the struct instance is used just once and then immediately got\n> discarded. As long as the object that gets passed this way does not\n> hold resources that need to be discarded itself (in other words,\n> does not require a call to reset_head_opts_release()), it makes the\n> code easier to follow.\n> \n> But once the struct gains members that need to be released, I am not\n> sure if this construct does not make it harder to spot leaks.\n> Somebody who adds a member to _release() to the struct presumably\n> audits and find all places that need to call _release(), but among\n> them they find this place---now what? They need to first convert it\n> to the old fashioned way and then call _release() after the\n> reset_head() call returns, I guess.\n> \n> I am not arguing against all uses of literals---I am just\n> anticipating future fallouts of encouraging overuse of this pattern,\n> and preparing what we would say when somebody adds a new use to\n> inappropriate places. Simple cases like the initialier should be\n> fine.\n\nWe already have a two test balloons, both defined in\n\"reftable/system.h\":\n\n #define REFTABLE_FLOCK_INIT ((struct reftable_flock){ .fd = -1, })\n\n #define REFTABLE_TMPFILE_INIT ((struct reftable_tmpfile) { .fd = -1, })\n\nBoth of those are getting used in a way that'd break if those weren't\nproperly supported in \"reftable/stack.c\":\n\n\tfor (i = 0; i < last - first + 1; i++)\n\t\ttable_locks[i] = REFTABLE_FLOCK_INIT;\n\n\ttab_file = REFTABLE_TMPFILE_INIT;\n\nThose are rather recent additions though, released with Git 2.50. I also\ntotally missed that we didn't have any test balloons for this syntax.\nShould we maybe retroactively mark them as test balloons instead of\nconverting and marking some new sites?\n\nPatrick\n"},{"id":"521956","messageId":"fb14ecec-a169-4182-a474-42f8567f5537@gmail.com","threadId":"63792","inReplyTo":"aHYXJ7EmRQE1P5xe@pks.im","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-07-15T09:44:20Z","receivedAt":"2025-07-15T09:44:26Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Patrick\n\nOn 15/07/2025 09:53, Patrick Steinhardt wrote:\n> \n> We already have a two test balloons, both defined in\n> \"reftable/system.h\":\n> \n> #define REFTABLE_FLOCK_INIT ((struct reftable_flock){ .fd = -1, })\n> \n> #define REFTABLE_TMPFILE_INIT ((struct reftable_tmpfile) { .fd = -1, })\n> \n> Both of those are getting used in a way that'd break if those weren't\n> properly supported in \"reftable/stack.c\":\n> \n> \tfor (i = 0; i < last - first + 1; i++)\n> \t\ttable_locks[i] = REFTABLE_FLOCK_INIT;\n> \n> \ttab_file = REFTABLE_TMPFILE_INIT;\n> \n> Those are rather recent additions though, released with Git 2.50. I also\n> totally missed that we didn't have any test balloons for this syntax.\n> Should we maybe retroactively mark them as test balloons instead of\n> converting and marking some new sites?\n\nIt would definitely be worth marking them as test balloons. So long as \nit is not possible to build git without the reftable library then they \nshould suffice without adding any more. I think it would be worth adding \na section to CodingGuildlines.adoc about the balloons we current have as \nwell (I didn't add that here as I wanted to wait until we knew the \ncommit id that introduced the balloon).\n\nThanks\n\nPhillip\n\n"},{"id":"522009","messageId":"xmqqqzyhifrr.fsf@gitster.g","threadId":"63792","inReplyTo":"aHYXJ7EmRQE1P5xe@pks.im","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-15T16:24:08Z","receivedAt":"2025-07-15T16:24:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> We already have a two test balloons, both defined in\n> \"reftable/system.h\":\n>\n> #define REFTABLE_FLOCK_INIT ((struct reftable_flock){ .fd = -1, })\n>\n> #define REFTABLE_TMPFILE_INIT ((struct reftable_tmpfile) { .fd = -1, })\n>\n> Both of those are getting used in a way that'd break if those weren't\n> properly supported in \"reftable/stack.c\":\n>\n> \tfor (i = 0; i < last - first + 1; i++)\n> \t\ttable_locks[i] = REFTABLE_FLOCK_INIT;\n>\n> \ttab_file = REFTABLE_TMPFILE_INIT;\n>\n> Those are rather recent additions though, released with Git 2.50. I also\n> totally missed that we didn't have any test balloons for this syntax.\n> Should we maybe retroactively mark them as test balloons instead of\n> converting and marking some new sites?\n\nThat sounds good. I was wondering if it is easier to keep track of\nthings to add a new section to the CodingGuildlines document,\nperhaps like this?\n\n Documentation/CodingGuidelines | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\nindex 6350949f2e..dd3dbb9c57 100644\n--- c/Documentation/CodingGuidelines\n+++ w/Documentation/CodingGuidelines\n@@ -298,6 +298,14 @@ For C programs:\n . since late 2021 with 44ba10d6, we have had variables declared in\n the for loop \"for (int i = 0; i < 10; i++)\".\n \n+ C99 features we have test balloons for:\n+\n+ . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n+ compound literal syntax, e.g., (struct foo){ .member = value };\n+ our hope is that no platforms we care about have trouble using\n+ them, and officially adopt its wider use in mid 2026. Do not add\n+ more use of the syntax until that happens.\n+\n New C99 features that we cannot use yet:\n \n . %z and %zu as a printf() argument for a size_t (the %z being for\n"},{"id":"522108","messageId":"ecca4252-1c29-4661-a454-a4cedc28bead@gmail.com","threadId":"63792","inReplyTo":"xmqqqzyhifrr.fsf@gitster.g","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-07-16T14:29:51Z","receivedAt":"2025-07-16T14:30:01Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 15/07/2025 17:24, Junio C Hamano wrote:\n> \n> That sounds good. I was wondering if it is easier to keep track of\n> things to add a new section to the CodingGuildlines document,\n> perhaps like this?\n\nThat's a good idea\n\nThanks\n\nPhillip\n\n> Documentation/CodingGuidelines | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n> diff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\n> index 6350949f2e..dd3dbb9c57 100644\n> --- c/Documentation/CodingGuidelines\n> +++ w/Documentation/CodingGuidelines\n> @@ -298,6 +298,14 @@ For C programs:\n> . since late 2021 with 44ba10d6, we have had variables declared in\n> the for loop \"for (int i = 0; i < 10; i++)\".\n> \n> + C99 features we have test balloons for:\n> +\n> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n> + compound literal syntax, e.g., (struct foo){ .member = value };\n> + our hope is that no platforms we care about have trouble using\n> + them, and officially adopt its wider use in mid 2026. Do not add\n> + more use of the syntax until that happens.\n> +\n> New C99 features that we cannot use yet:\n> \n> . %z and %zu as a printf() argument for a size_t (the %z being for\n\n"},{"id":"522109","messageId":"9532e4de-1f19-43a0-bf9d-9f93ca0fafd5@gmail.com","threadId":"63792","inReplyTo":"xmqqa556x2z4.fsf@gitster.g","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-07-16T14:32:50Z","receivedAt":"2025-07-16T14:32:59Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 14/07/2025 15:26, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>> From: Phillip Wood \n>>\n>> A C99 compound literal creates an unnamed object whose value is given by\n>> an initializer list. This allows us to simplify code where we cannot use\n>> a designated initalizer because the values of some members of the object\n>> need to be calculated first. For example this code from builtin/rebase.c\n>>\n>> \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n>> \tstruct reset_head_opts ropts = { 0 };\n>> \tint ret;\n>>\n>> \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n>> \t\t opts->reflog_action,\n>> \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n>> \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n>> \t\t opts->reflog_action, opts->head_name);\n>> \tropts.branch = opts->head_name;\n>> \tropts.flags = RESET_HEAD_REFS_ONLY;\n>> \tropts.branch_msg = branch_reflog.buf;\n>> \tropts.head_msg = head_reflog.buf;\n>> \tret = reset_head(the_repository, &ropts);\n>>\n>> can be be simplified to\n>>\n>> \tstruct strbuf branch_reflog = STRBUF_INIT, head_reflog = STRBUF_INIT;\n>> \tint ret;\n>>\n>> \tstrbuf_addf(&branch_reflog, \"%s (finish): %s onto %s\",\n>> \t\t opts->reflog_action,\n>> \t\t opts->head_name, oid_to_hex(&opts->onto->object.oid));\n>> \tstrbuf_addf(&head_reflog, \"%s (finish): returning to %s\",\n>> \t\t opts->reflog_action, opts->head_name);\n>> ret = reset_head(the_repository, &(struct reset_head_opts) {\n>> .branch = opts->head_name,\n>> \t.flags = RESET_HEAD_REFS_ONLY,\n>> \t.branch_msg = branch_reflog.buf,\n>> \t.head_msg = head_reflog.buf,\n>> });\n>>\n> > One thing the above rewrite did is to make it clear to readers that\n> the struct instance is used just once and then immediately got\n> discarded. As long as the object that gets passed this way does not\n> hold resources that need to be discarded itself (in other words,\n> does not require a call to reset_head_opts_release()), it makes the\n> code easier to follow.\n\nThat's a good point - this example would not work if reset_head_opts() \ntook ownership of `branch_msg` and `head_msg`.\n\n> But once the struct gains members that need to be released, I am not\n> sure if this construct does not make it harder to spot leaks.\n> Somebody who adds a member to _release() to the struct presumably\n> audits and find all places that need to call _release(), but among\n> them they find this place---now what? They need to first convert it\n> to the old fashioned way and then call _release() after the\n> reset_head() call returns, I guess.\nAnother possibility is to do something like\n\n\tstruct reset_head_opts ropts;\n\n\t/* ... */\n\n\tropts = (struct replay_head_opts) {\n\t\t...\n\t};\n\n\tret = reset_head(the_repository, &ropts);\n\n\treset_head_opts_release(&ropts);\n\nwhich initializes all the members of `ropts` in one place though I'm not \nsure if it is really better in practice.\n> I am not arguing against all uses of literals---I am just\n> anticipating future fallouts of encouraging overuse of this pattern,\n> and preparing what we would say when somebody adds a new use to\n> inappropriate places. Simple cases like the initialier should be\n> fine.\n\nYes, we'd want to be careful where we use them. I like the way we use \ndesignated initializers and this gives us the opportunity to have a \nsimilar style of initialization in a few more places.\n\nThanks\n\nPhillip\n\n"},{"id":"522596","messageId":"xmqqldoen5v3.fsf@gitster.g","threadId":"63792","inReplyTo":"ecca4252-1c29-4661-a454-a4cedc28bead@gmail.com","subject":"Re: [PATCH] strbuf: add compound literal test balloon","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-23T18:01:52Z","receivedAt":"2025-07-23T18:01:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> On 15/07/2025 17:24, Junio C Hamano wrote:\n>> That sounds good. I was wondering if it is easier to keep track of\n>> things to add a new section to the CodingGuildlines document,\n>> perhaps like this?\n>\n> That's a good idea\n>\n> Thanks\n>\n> Phillip\n\nI guess I dropped the ball after this exchange. So our tentative\nconclusion was to drop your new test balloon, and replace it with\nthe documentation patch you are responding to, which I obviously\nam OK with.\n\nLet me make it happen.\n\nThanks.\n\n\n>\n>> Documentation/CodingGuidelines | 8 ++++++++\n>> 1 file changed, 8 insertions(+)\n>> diff --git c/Documentation/CodingGuidelines\n>> w/Documentation/CodingGuidelines\n>> index 6350949f2e..dd3dbb9c57 100644\n>> --- c/Documentation/CodingGuidelines\n>> +++ w/Documentation/CodingGuidelines\n>> @@ -298,6 +298,14 @@ For C programs:\n>> . since late 2021 with 44ba10d6, we have had variables declared in\n>> the for loop \"for (int i = 0; i < 10; i++)\".\n>> + C99 features we have test balloons for:\n>> +\n>> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n>> + compound literal syntax, e.g., (struct foo){ .member = value };\n>> + our hope is that no platforms we care about have trouble using\n>> + them, and officially adopt its wider use in mid 2026. Do not add\n>> + more use of the syntax until that happens.\n>> +\n>> New C99 features that we cannot use yet:\n>> . %z and %zu as a printf() argument for a size_t (the %z\n>> being for\n"},{"id":"522601","messageId":"xmqqecu6n1pt.fsf@gitster.g","threadId":"63792","inReplyTo":"xmqqldoen5v3.fsf@gitster.g","subject":"[PATCH] CodingGuidelines: document test balloons in flight","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-23T19:31:26Z","receivedAt":"2025-07-23T19:31:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Due to portability concerns, we do not blindly say \"It is in [[this\nstandard]], so we will make liberal use of it\" for many features,\nand use of C99 language features follow this same principle. When\nwe contemplate adopting a language feature that we haven't used in\nour codebase, we typically first raise a test balloon, which\n\n - is a piece of code that exercises the language feature we are\n trying to see if it is OK to adopt\n\n - is in a small section of code that we know everybody who cares\n about having a working Git must be compiling\n\n - is in a fairly stable part of the code, to allow reverting it\n easily if some platforms do not understand it yet.\n\nAfter a few years, with no breakage report from the community, we'd\ndeclare that the feature is now safe to use in our codebase. Before\nthat, we forbid the use of the language construct except for the\ndesignated test balloon code site.\n\nThe CodingGuidelines document lists these selected features that we\nalready have determined that they are safe, and also those features\nthat we know some platforms had trouble with.\n\nLet's also start listing ongoing test balloons and expected timeline\nfor adoption.\n\nHelped-by: Phillip Wood \nSigned-off-by: Junio C Hamano \n---\n Documentation/CodingGuidelines | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex c1046abfb7..0776d15a95 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -298,6 +298,14 @@ For C programs:\n . since late 2021 with 44ba10d6, we have had variables declared in\n the for loop \"for (int i = 0; i < 10; i++)\".\n \n+ C99 features we have test balloons for:\n+\n+ . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n+ compound literal syntax, e.g., (struct foo){ .member = value };\n+ our hope is that no platforms we care about have trouble using\n+ them, and officially adopt its wider use in mid 2026. Do not add\n+ more use of the syntax until that happens.\n+\n New C99 features that we cannot use yet:\n \n . %z and %zu as a printf() argument for a size_t (the %z being for\n-- \n2.50.1-521-gf11ee0bd80\n\n"},{"id":"522631","messageId":"aIHY-PXYYzE8JULj@pks.im","threadId":"63792","inReplyTo":"xmqqecu6n1pt.fsf@gitster.g","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-07-24T06:55:52Z","receivedAt":"2025-07-24T06:55:59Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Jul 23, 2025 at 12:31:26PM -0700, Junio C Hamano wrote:\n> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> index c1046abfb7..0776d15a95 100644\n> --- a/Documentation/CodingGuidelines\n> +++ b/Documentation/CodingGuidelines\n> @@ -298,6 +298,14 @@ For C programs:\n> . since late 2021 with 44ba10d6, we have had variables declared in\n> the for loop \"for (int i = 0; i < 10; i++)\".\n> \n> + C99 features we have test balloons for:\n> +\n> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n> + compound literal syntax, e.g., (struct foo){ .member = value };\n> + our hope is that no platforms we care about have trouble using\n> + them, and officially adopt its wider use in mid 2026. Do not add\n> + more use of the syntax until that happens.\n\nNice. I like that we now have an explicit deadline for people to\ncomplain about this feature not being supported on their platform.\n\nSo this looks good to me, thanks!\n\nPatrick\n"},{"id":"522667","messageId":"f954683b-b0be-4608-814d-23993316fcc2@gmail.com","threadId":"63792","inReplyTo":"xmqqecu6n1pt.fsf@gitster.g","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-07-24T14:26:33Z","receivedAt":"2025-07-24T14:26:36Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Junio\n\nOn 23/07/2025 20:31, Junio C Hamano wrote:\n> Due to portability concerns, we do not blindly say \"It is in [[this\n> standard]], so we will make liberal use of it\" for many features,\n> and use of C99 language features follow this same principle. When\n> we contemplate adopting a language feature that we haven't used in\n> our codebase, we typically first raise a test balloon, which\n> \n> - is a piece of code that exercises the language feature we are\n> trying to see if it is OK to adopt\n> \n> - is in a small section of code that we know everybody who cares\n> about having a working Git must be compiling\n> \n> - is in a fairly stable part of the code, to allow reverting it\n> easily if some platforms do not understand it yet.\n> \n> After a few years, with no breakage report from the community, we'd\n> declare that the feature is now safe to use in our codebase. Before\n> that, we forbid the use of the language construct except for the\n> designated test balloon code site.\n> \n> The CodingGuidelines document lists these selected features that we\n> already have determined that they are safe, and also those features\n> that we know some platforms had trouble with.\n> \n> Let's also start listing ongoing test balloons and expected timeline\n> for adoption.\n> \n> Helped-by: Phillip Wood \n\nI'm not sure what I've done to deserve that - it was Patrick that \npointed out the test balloon already existed. The patch and the commit \nmessage look good to me.\n\nThanks\n\nPhillip\n\n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/CodingGuidelines | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> index c1046abfb7..0776d15a95 100644\n> --- a/Documentation/CodingGuidelines\n> +++ b/Documentation/CodingGuidelines\n> @@ -298,6 +298,14 @@ For C programs:\n> . since late 2021 with 44ba10d6, we have had variables declared in\n> the for loop \"for (int i = 0; i < 10; i++)\".\n> \n> + C99 features we have test balloons for:\n> +\n> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n> + compound literal syntax, e.g., (struct foo){ .member = value };\n> + our hope is that no platforms we care about have trouble using\n> + them, and officially adopt its wider use in mid 2026. Do not add\n> + more use of the syntax until that happens.\n> +\n> New C99 features that we cannot use yet:\n> \n> . %z and %zu as a printf() argument for a size_t (the %z being for\n\n"},{"id":"522687","messageId":"xmqqseilimlp.fsf@gitster.g","threadId":"63792","inReplyTo":"f954683b-b0be-4608-814d-23993316fcc2@gmail.com","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-24T16:23:46Z","receivedAt":"2025-07-24T16:23:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> Hi Junio\n>\n> On 23/07/2025 20:31, Junio C Hamano wrote:\n>> Due to portability concerns, we do not blindly say \"It is in [[this\n>> standard]], so we will make liberal use of it\" for many features,\n>> and use of C99 language features follow this same principle. When\n>> we contemplate adopting a language feature that we haven't used in\n>> our codebase, we typically first raise a test balloon, which\n>> - is a piece of code that exercises the language feature we are\n>> trying to see if it is OK to adopt\n>> - is in a small section of code that we know everybody who cares\n>> about having a working Git must be compiling\n>> - is in a fairly stable part of the code, to allow reverting it\n>> easily if some platforms do not understand it yet.\n>> After a few years, with no breakage report from the community, we'd\n>> declare that the feature is now safe to use in our codebase. Before\n>> that, we forbid the use of the language construct except for the\n>> designated test balloon code site.\n>> The CodingGuidelines document lists these selected features that we\n>> already have determined that they are safe, and also those features\n>> that we know some platforms had trouble with.\n>> Let's also start listing ongoing test balloons and expected timeline\n>> for adoption.\n>> Helped-by: Phillip Wood \n>\n> I'm not sure what I've done to deserve that - it was Patrick that\n> pointed out the test balloon already existed. The patch and the commit\n> message look good to me.\n\nLet me assign equal credit to Patrick. Thanks.\n\n>> Signed-off-by: Junio C Hamano \n>> ---\n>> Documentation/CodingGuidelines | 8 ++++++++\n>> 1 file changed, 8 insertions(+)\n>> diff --git a/Documentation/CodingGuidelines\n>> b/Documentation/CodingGuidelines\n>> index c1046abfb7..0776d15a95 100644\n>> --- a/Documentation/CodingGuidelines\n>> +++ b/Documentation/CodingGuidelines\n>> @@ -298,6 +298,14 @@ For C programs:\n>> . since late 2021 with 44ba10d6, we have had variables declared in\n>> the for loop \"for (int i = 0; i < 10; i++)\".\n>> + C99 features we have test balloons for:\n>> +\n>> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n>> + compound literal syntax, e.g., (struct foo){ .member = value };\n>> + our hope is that no platforms we care about have trouble using\n>> + them, and officially adopt its wider use in mid 2026. Do not add\n>> + more use of the syntax until that happens.\n>> +\n>> New C99 features that we cannot use yet:\n>> . %z and %zu as a printf() argument for a size_t (the %z\n>> being for\n"},{"id":"522688","messageId":"xmqqms8tilvs.fsf@gitster.g","threadId":"63792","inReplyTo":"aIHY-PXYYzE8JULj@pks.im","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-24T16:39:19Z","receivedAt":"2025-07-24T16:39:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> On Wed, Jul 23, 2025 at 12:31:26PM -0700, Junio C Hamano wrote:\n>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n>> index c1046abfb7..0776d15a95 100644\n>> --- a/Documentation/CodingGuidelines\n>> +++ b/Documentation/CodingGuidelines\n>> @@ -298,6 +298,14 @@ For C programs:\n>> . since late 2021 with 44ba10d6, we have had variables declared in\n>> the for loop \"for (int i = 0; i < 10; i++)\".\n>> \n>> + C99 features we have test balloons for:\n>> +\n>> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n>> + compound literal syntax, e.g., (struct foo){ .member = value };\n>> + our hope is that no platforms we care about have trouble using\n>> + them, and officially adopt its wider use in mid 2026. Do not add\n>> + more use of the syntax until that happens.\n>\n> Nice. I like that we now have an explicit deadline for people to\n> complain about this feature not being supported on their platform.\n\nI do not think the firm deadline has much practical effect. Test\nballoons are designed to be placed in a stable and non-optional part\nof the codebase that is exercised by everybody, so even if your\nupdate cycle from your upstream is once a year, you'd have four or\nfive major releases to try building and noticing that your platform\nis unhappy about them.\n\nSo the only effect it would have is to smoke out truly slow platform\nmaintainers; if their users are happy enough with such slow upgrade,\nthey have lived and they can live with versions of Git that are\nyears stale that we no longer care about.\n\n\n"},{"id":"522690","messageId":"m1seily1e3.fsf@gmail.com","threadId":"63792","inReplyTo":"xmqqms8tilvs.fsf@gitster.g","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Collin Funk","fromEmail":"collin.funk1@gmail.com","sentAt":"2025-07-24T16:55:16Z","receivedAt":"2025-07-24T16:55:17Z","isPatch":true,"sender":{"key":"collin.funk1@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65689063?v=4"},"body":"Junio C Hamano writes:\n\n> Patrick Steinhardt writes:\n>\n>> On Wed, Jul 23, 2025 at 12:31:26PM -0700, Junio C Hamano wrote:\n>>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n>>> index c1046abfb7..0776d15a95 100644\n>>> --- a/Documentation/CodingGuidelines\n>>> +++ b/Documentation/CodingGuidelines\n>>> @@ -298,6 +298,14 @@ For C programs:\n>>> . since late 2021 with 44ba10d6, we have had variables declared in\n>>> the for loop \"for (int i = 0; i < 10; i++)\".\n>>> \n>>> + C99 features we have test balloons for:\n>>> +\n>>> + . since late 2024 with v2.48.0-rc0~20, we have test balloons for\n>>> + compound literal syntax, e.g., (struct foo){ .member = value };\n>>> + our hope is that no platforms we care about have trouble using\n>>> + them, and officially adopt its wider use in mid 2026. Do not add\n>>> + more use of the syntax until that happens.\n>>\n>> Nice. I like that we now have an explicit deadline for people to\n>> complain about this feature not being supported on their platform.\n>\n> I do not think the firm deadline has much practical effect. Test\n> balloons are designed to be placed in a stable and non-optional part\n> of the codebase that is exercised by everybody, so even if your\n> update cycle from your upstream is once a year, you'd have four or\n> five major releases to try building and noticing that your platform\n> is unhappy about them.\n>\n> So the only effect it would have is to smoke out truly slow platform\n> maintainers; if their users are happy enough with such slow upgrade,\n> they have lived and they can live with versions of Git that are\n> years stale that we no longer care about.\n\n\nFor what it is worth, Gnulib and threfore Coreutils, among others, began\nusing compound literals in 2017 and it seems to have not caused any\nproblems [1]. Even 'pcc' supports them.\n\nCollin\n\n[1] https://github.com/coreutils/gnulib/commit/3a8af1e38bc026a9efb3b47c4686e4e54b633436\n"},{"id":"522816","messageId":"xmqqcy9m1r3q.fsf@gitster.g","threadId":"63792","inReplyTo":"m1seily1e3.fsf@gmail.com","subject":"Re: [PATCH] CodingGuidelines: document test balloons in flight","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-26T23:15:21Z","receivedAt":"2025-07-26T23:15:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Collin Funk writes:\n\n>> So the only effect it would have is to smoke out truly slow platform\n>> maintainers; if their users are happy enough with such slow upgrade,\n>> they have lived and they can live with versions of Git that are\n>> years stale that we no longer care about.\n>\n>\n> For what it is worth, Gnulib and threfore Coreutils, among others, began\n> using compound literals in 2017 and it seems to have not caused any\n> problems [1]. Even 'pcc' supports them.\n\nThanks. Our worry however includes platforms outside the Open\nSource and/or Free Software ecosystem, which would not be helped\nvery much.\n\n"}]}