Re: [PATCH] CodingGuidelines: allow compound literals

[Phillip Wood <phillip.wood123@gmail.com>]

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