Re: [PATCH 1/3] test-tool genzeros: initialize "zeros" to avoid SunCC warning

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2022, 17:38 UTC
Message-ID: <xmqqee5bk02j.fsf@gitster.g>
In-Reply-To: <220113.8635lsvsw6.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 26 quoted lines

> On Wed, Jan 12 2022, Taylor Blau wrote:
>
>> On Wed, Jan 12, 2022 at 03:21:46PM +0100, Johannes Schindelin wrote:
>>> > diff --git a/t/helper/test-genzeros.c b/t/helper/test-genzeros.c
>>> > index 8ca988d6216..5dc89eda0cb 100644
>>> > --- a/t/helper/test-genzeros.c
>>> > +++ b/t/helper/test-genzeros.c
>>> > @@ -3,8 +3,7 @@
>>> >
>>> >  int cmd__genzeros(int argc, const char **argv)
>>> >  {
>>> > -	/* static, so that it is NUL-initialized */
>>> > -	static const char zeros[256 * 1024];
>>> > +	const char zeros[256 * 1024] = { 0 };
>>>
>>> This diff does two things: add an initializer, and turn the variable into
>>> a `static`. The former is the actual fix that is required. The latter is
>>> not. During the -rc phase, we do not want to see any of the latter. It is
>>> unnecessarily controversial and distracting, and can easily be postponed
>>> until January 25th, 2022.
>>
>> This assumes that making the declaration non-static isn't necessary to
>> fix the warning from SunCC.
>
> Just adding "= { 0 }" and retaining the "static" would FWIW make SunCC
> happy here.

It would make folks, who worry about having too large an item on the stack to begin with, happy, too. 256kB on stack of a function that does not make a call into a deep call chain would not matter all that much, but it is a good principle to keep in mind.

We've worked around false "uninitialized" alarms from too picky (versions of) compilers before by adding an otherwise unnecessary initializers before, and I think this falls into the same category.

It is a separate matter if it is appropriate to worry about SunCC this late in the cycle. If this were "we were clean before, and these small number of places add breakages", I would say yes.

But if this is "let's not add more of the same existing breakage that we already have tons", we should not even be discussing about such a change this late in the cycle (immediately after the new offenders were added would have been more appropriate).

I offhand do not know which side of that line this one falls, though.

Thanks.