Eric Sunshine [off-list ref] writes:

quoted

quoted

    % git grep -n '{ *{ *0 *} *}'
    builtin/merge-file.c:31: xmparam_t xmp = {{0}};

Not so fast :) If you check out "next", does compiling
builtin/merge-file.o there complain on that clang version now? I changed
this to the "{ 0 }" form.

No, builtin/merge-file.c doesn't compile, and I discovered that just
after sending the email to which you responded. I haven't yet prepared
a patch for that new instance since I don't know if Junio feels
inclined to pick up such a change.

Wait, what do you mean by "doesn't compile"?  The compiler totally
chokes on "{ 0 } recursively zero initializes" idiom and does not
know what binary to produce, or it merely warns even though it knows
what to do with the code, but because we choose to give -Werror, it
is stopped from producing a binary?

quoted

It is nice though to be able to use standard C99 consistently, where a
"{ 0 }" recursively initializes the members, I think that's what your
clang version is doing, it's just complaining about it.

Agreed, it would be nice to use plain `{0}`.

quoted

Since this is only a warning, and only a practical issue with -Werror I
wonder if a config.mak.dev change wouldn't be better, i.e. to provide a
-Wno-missing-braces for this older clang version.

I'm in favor of this. It would, of course, require extra
special-casing for Apple's clang for which the version number bears no
resemblance to reality since Apple invents their own version numbers.

I guess from this that you meant "we get an erroneous warning".  If
so, I am in favor of squelching the warning.