[PATCH] CodingGuidelines: allow compound literals

[PATCH] CodingGuidelines: allow compound literals

[Phillip Wood]

From: Phillip Wood <phillip.wood@dunelm.org.uk>

Our coding guidelines say that we'll allow compound literals from
mid 2026 if no problems are reported in relation to the test balloon
added in 01e49941d6 (reftable/system: provide thin wrapper for tempfile
subsystem, 2024-11-18). As no such reports have been received, update
the guidelines to allow this construct.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
base-commit: 26d8d94e94df5535eecd036f16627493506a0614
Published-As: https://github.com/phillipwood/git/releases/tag/pw%2Fcoding-guidelines-allow-compound-literals%2Fv1
View-Changes-At: https://github.com/phillipwood/git/compare/26d8d94e9...a4b382c03
Fetch-It-Via: git fetch https://github.com/phillipwood/git pw/coding-guidelines-allow-compound-literals/v1

 Documentation/CodingGuidelines | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index c06f5d3071..23a4d2186a 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -311,13 +311,8 @@ For C programs:
    . since late 2023 with 8277dbe987 we have been using the bool type
      from <stdbool.h>.
 
-   C99 features we have test balloons for:
-
-   . since late 2024 with v2.48.0-rc0~20, we have test balloons for
-     compound literal syntax, e.g., (struct foo){ .member = value };
-     our hope is that no platforms we care about have trouble using
-     them, and officially adopt its wider use in mid 2026.  Do not add
-     more use of the syntax until that happens.
+   . since late 2024 with v2.48.0-rc0~20, we have been using compound
+     literals, e.g., (struct foo){ .member = value };
 
    New C99 features that we cannot use yet:
 
-- 
2.56.0.336.g97505d19352

Re: [PATCH] CodingGuidelines: allow compound literals

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> Our coding guidelines say that we'll allow compound literals from
> mid 2026 if no problems are reported in relation to the test balloon
> added in 01e49941d6 (reftable/system: provide thin wrapper for tempfile
> subsystem, 2024-11-18). As no such reports have been received, update
> the guidelines to allow this construct.
>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---

Yeah, I agree that it is about time to promote this to the accepted
set.

So we do not have test balloon but we know we still cannot use two
constructs from C99 due to MinGW and older IBM xlc?  Perhaps we can
raise test balloons for them by now?

Will merge and mark the topic as ready for 'next'.  Thanks.

> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index c06f5d3071..23a4d2186a 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -311,13 +311,8 @@ For C programs:
>     . since late 2023 with 8277dbe987 we have been using the bool type
>       from <stdbool.h>.
>  
> -   C99 features we have test balloons for:
> -
> -   . since late 2024 with v2.48.0-rc0~20, we have test balloons for
> -     compound literal syntax, e.g., (struct foo){ .member = value };
> -     our hope is that no platforms we care about have trouble using
> -     them, and officially adopt its wider use in mid 2026.  Do not add
> -     more use of the syntax until that happens.
> +   . since late 2024 with v2.48.0-rc0~20, we have been using compound
> +     literals, e.g., (struct foo){ .member = value };
>  
>     New C99 features that we cannot use yet:

Re: [PATCH] CodingGuidelines: allow compound literals

[Patrick Steinhardt]

On Mon, Oct 26, 2026 at 02:11:08PM -0700, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> > From: Phillip Wood <phillip.wood@dunelm.org.uk>
> >
> > Our coding guidelines say that we'll allow compound literals from
> > mid 2026 if no problems are reported in relation to the test balloon
> > added in 01e49941d6 (reftable/system: provide thin wrapper for tempfile
> > subsystem, 2024-11-18). As no such reports have been received, update
> > the guidelines to allow this construct.
> >
> > Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> > ---
> 
> Yeah, I agree that it is about time to promote this to the accepted
> set.
> 
> So we do not have test balloon but we know we still cannot use two
> constructs from C99 due to MinGW and older IBM xlc?  Perhaps we can
> raise test balloons for them by now?

Huh, which are those two constructs?

This also makes me wonder whether we should have a look at what C11 has
to offer. Skimming through it though the only thing that I do find to be
interesting is `_static_assert()`. We essentially already have those,
but they are extremely hacky and their error messages leave a lot to be
desired.

C17 is rather uninteresting, and the next version that provides some
significant value is C23. But that one is probably way too fancy and new
to be a sensible target for us now.

> Will merge and mark the topic as ready for 'next'.  Thanks.

Yup, agreed.

One thing I wonder is whether we can now start to replace the split
between e.g. `STRBUF_INIT` and `strbuf_init()`. Right now the issue here
is that you cannot initialize a variable at a later point like this:

  struct strbuf buf;

  buf = STRBUF_INIT;

This is because `STRBUF_INIT` is simply defined as `{ .buf = ... }`, and
thus the compiler would complain. So instead, you are forced to now call
`strbuf_init()` on that variable.

But with compound literals we can define it as `#define STRBUF_INIT
((struct strbuf) { .buf = ... }`, which would make the above code to
compile just fine. And as a consequence, `strbuf_init()` essentially
becomes obsolete.

Now I'm of course not proposing to go on a crusade and replace every
such site, and I only use `strbuf` as an example here. But is that a
direction we want to move towards?

Patrick

Re: [PATCH] CodingGuidelines: allow compound literals

[Phillip Wood]

On 27/10/2026 06:36, Patrick Steinhardt wrote:
> On Mon, Oct 26, 2026 at 02:11:08PM -0700, Junio C Hamano wrote:
>>
>> So we do not have test balloon but we know we still cannot use two
>> constructs from C99 due to MinGW and older IBM xlc?  Perhaps we can
>> raise test balloons for them by now?
> 
> Huh, which are those two constructs?

The format specifiers "%z", "%zu" due to MinGW and ".a.b = c" in struct 
initializers due to IBM xlc. I've cc'd Johannes to see if the changes 
around using UCRT64 makes any difference to the format specifier support.

> This also makes me wonder whether we should have a look at what C11 has
> to offer. Skimming through it though the only thing that I do find to be
> interesting is `_static_assert()`. We essentially already have those,
> but they are extremely hacky and their error messages leave a lot to be
> desired.

Yes static_assert() would be nice. Atomics might be useful to reduce the 
amount of undefined behavior in our signal handling but I've a feeling 
they're optional. Would _Generic macros be useful anywhere?

> One thing I wonder is whether we can now start to replace the split
> between e.g. `STRBUF_INIT` and `strbuf_init()`. Right now the issue here
> is that you cannot initialize a variable at a later point like this:
> 
>    struct strbuf buf;
> 
>    buf = STRBUF_INIT;
> 
> This is because `STRBUF_INIT` is simply defined as `{ .buf = ... }`, and
> thus the compiler would complain. So instead, you are forced to now call
> `strbuf_init()` on that variable.
> 
> But with compound literals we can define it as `#define STRBUF_INIT
> ((struct strbuf) { .buf = ... }`, which would make the above code to
> compile just fine. And as a consequence, `strbuf_init()` essentially
> becomes obsolete.

That would match what the test balloon was doing for temp file 
implementation in the reftable code I think. It's probably worth 
converting STRBUF_INIT() to give us that option for new code. 
strbuf_init() takes a size to pre-allocate "buf" but most callers pass 0 
for that parameter and I wonder how scientific the hard coded values 
below are.

git grep strbuf_init | sed 's/.*strbuf_init([^,]*, *\([^)]*\).*/\1/' | 
sort | uniq --count
      79 0
       1 100
       1 1000
       8 1024
       2 256
       2 256 * (32 + the_hash_algo->hexsz
       1 32
       1 80
       1 8192
       2 b_seg->len
       1 dirnamelen + 257
       1 dots - name
       3 from->len
       1 ident_len
       1 imgoff + extra_chars
       2 len
       1 len+32
      10 line->len
       5 PATH_MAX
       1 PATH_MAX * 2 + 300
       1 PATH_MAX + len + 1
       2 q_seg->len
       1 sb_src->len
       2 size
       1 size_t alloc
       1 size_t hint
       1 strlen(arg
       1 strlen(url_decoded
       1 tgtlen
       1 though.
       1 url_len

> Now I'm of course not proposing to go on a crusade and replace every
> such site, and I only use `strbuf` as an example here. But is that a
> direction we want to move towards?

I think it would be nice to have a uniform way of initializing structs 
like strbuf that works whether they are allocated on the stack (where 
we've traditionally used *_INIT macros) or on the heap (where we've 
traditionally used *_init() functions).

Thanks

Phillip