Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>> > % 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?
>> 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}`.
>
>> 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.
