From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Han Xin" <chiyutianyi@gmail.com>,
"Git List" <git@vger.kernel.org>
Subject: Re: [PATCH] unpack-objects: fix compilation warning/error due to missing braces
Date: Tue, 12 Jul 2022 07:46:27 -0700 [thread overview]
Message-ID: <xmqqczeaie2k.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cSgNB=SzAZLhXvteSYmy0HvJh+qWHMYyBxcX_EA9__u4A@mail.gmail.com> (Eric Sunshine's message of "Tue, 12 Jul 2022 03:13:50 -0400")
Eric Sunshine <sunshine@sunshineco.com> 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.
prev parent reply other threads:[~2022-07-12 14:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-10 8:11 [PATCH] unpack-objects: fix compilation warning/error due to missing braces Eric Sunshine
2022-07-11 2:00 ` Han Xin
2022-07-11 2:41 ` Eric Sunshine
2022-07-11 4:38 ` Junio C Hamano
2022-07-12 6:28 ` Eric Sunshine
2022-07-12 6:41 ` Ævar Arnfjörð Bjarmason
2022-07-12 7:13 ` Eric Sunshine
2022-07-12 7:23 ` Jeff King
2022-07-12 7:33 ` Eric Sunshine
2022-07-12 9:16 ` Ævar Arnfjörð Bjarmason
2022-07-14 21:54 ` Jeff King
2022-07-15 8:20 ` Ævar Arnfjörð Bjarmason
2022-07-12 14:46 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqczeaie2k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=chiyutianyi@gmail.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).