Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 16, 2019, 19:01 UTC
Message-ID: <xmqqo91t3itl.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190715181527.GA30747@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> But I'd be happy if we could address it in another way (e.g., convincing
> sparse to stop complaining about it, or just decide it's not worth
> dealing with). One other thing I haven't seen discussed in this thread:
> we could actually make our preferred style be for all structs to define
> a FOO_INIT initializer, like we already do for STRBUF_INIT, etc. That's
> a much more heavyweight solution than what's being discussed here, but
> it comes with an extra benefit: it's easy to catch and change all users
> if the struct switches away from zero-initialization.

I'd rather not to go that route.  When we say

	static struct foo foo;

we are happy with the natural and trivial zero initialization of the structure. If we didn't have to say STRBUF_INIT, the codebase would have been a lot nicer with less noise. Because the implementation of the strbuf cannot take the trivial zero initialized state as a valid one, we had to sprinkle " = STRBUF_INIT;" all over.

And that "quiet and nice" form is a moral equivalent of

	struct foo foo = { 0 };

that has been discussed in this thread. I'd rather not to see it turned into distinct FOO_INIT, BAR_INIT, etc. to force the reader to think these structures all need their specific initialization and wonder what's the reason for each of them.

One universal "struct foo foo = STRUCT_ZERO_INIT;" that is applied to all kinds of structure I could live with (but only if we have a good way to squelch sparse from bitching about it). Perhaps we could define it as "{}" for GCC, while keeping it "{ 0 }" for others. As I said, { 0 } is undefensible if we insist that a null pointer must be spelled NULL and not 0 (as CodingGuidelines says), but as long as we declare that we take "{ 0 }" as a mere convention (like we used to use the "int foo = foo;" convention to squelch "uninitialized but used" warnings) that is outside the purview of language-lawyers, I am perfectly fine with it, and if it is hidden behind a macro, that would be even better ;-)