All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org, Han-Wen Nienhuys <hanwen@google.com>
Subject: Re: [PATCH 1/3] test-tool genzeros: initialize "zeros" to avoid SunCC warning
Date: Thu, 13 Jan 2022 09:38:44 -0800	[thread overview]
Message-ID: <xmqqee5bk02j.fsf@gitster.g> (raw)
In-Reply-To: <220113.8635lsvsw6.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Thu, 13 Jan 2022 11:08:44 +0100")

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

> 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.


  parent reply	other threads:[~2022-01-13 17:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 16:40 [PATCH 0/3] Fix SunCC compiler complaints new in v2.35.0-rc0 Ævar Arnfjörð Bjarmason
2022-01-12  1:21 ` Emily Shaffer
2022-01-11 16:40 ` [PATCH 1/3] test-tool genzeros: initialize "zeros" to avoid SunCC warning Ævar Arnfjörð Bjarmason
2022-01-11 19:06   ` Taylor Blau
2022-01-12 14:21   ` Johannes Schindelin
2022-01-12 19:10     ` Taylor Blau
2022-01-13 10:08       ` Ævar Arnfjörð Bjarmason
2022-01-13 15:31         ` Johannes Schindelin
2022-01-13 17:38         ` Junio C Hamano [this message]
2022-01-11 16:40 ` [PATCH 2/3] reftable: remove unreachable "return" statements Ævar Arnfjörð Bjarmason
2022-01-11 19:16   ` Taylor Blau
2022-01-12 12:47     ` Ævar Arnfjörð Bjarmason
2022-01-12 19:19       ` Taylor Blau
2022-01-13 10:29         ` Ævar Arnfjörð Bjarmason
2022-01-13 15:39           ` Johannes Schindelin
2022-01-13 20:17       ` Johannes Sixt
2022-01-13 21:37         ` Junio C Hamano
2022-01-11 16:40 ` [PATCH 3/3] reftable tests: avoid "int" overflow, use "uint64_t" Ævar Arnfjörð Bjarmason
2022-01-11 19:28   ` Taylor Blau
2022-01-11 19:31     ` Han-Wen Nienhuys
2022-01-11 19:41       ` Taylor Blau
2022-01-11 20:08         ` Johannes Sixt
2022-01-11 20:18           ` Taylor Blau
2022-01-11 20:21             ` Johannes Sixt
2022-01-11 20:24               ` Taylor Blau
2022-01-12 14:18                 ` Johannes Schindelin
2022-01-12 19:02               ` Junio C Hamano
2022-01-12 19:07                 ` Taylor Blau
2022-01-13 10:04                   ` Ævar Arnfjörð Bjarmason
2022-01-13 21:38                     ` Junio C Hamano
2022-01-11 17:06 ` [PATCH 0/3] Fix SunCC compiler complaints new in v2.35.0-rc0 Han-Wen Nienhuys
2022-01-11 18:36   ` René Scharfe
2022-01-12  1:22 ` Emily Shaffer

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=xmqqee5bk02j.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hanwen@google.com \
    --cc=me@ttaylorr.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.