All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Han-Wen Nienhuys <hanwen@google.com>
Subject: Re: [PATCH 1/3] test-tool genzeros: initialize "zeros" to avoid SunCC warning
Date: Tue, 11 Jan 2022 14:06:18 -0500	[thread overview]
Message-ID: <Yd3VKjvb7AR0/wI9@nand.local> (raw)
In-Reply-To: <patch-1.3-4dadf7320ab-20220111T163908Z-avarab@gmail.com>

On Tue, Jan 11, 2022 at 05:40:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
> It isn't important for optimization to have this be "static", so let's
> just initialize it and avoid this warning on Sun Studio 12.5:
>
>     "t/helper/test-genzeros.c", line 7: warning: const object should have initializer: zeros

I agree that whether or not this variable is declared statically does
not matter for our purposes, since we call cmd__genzeros() exactly once
per invocation of the test helper. So we're never paying the cost to
re-declare a variable on the stack since that stack frame only gets
created once.

And I don't care for the purposes of a reroll on such a trivial
question, but I do think that this patch leaves something out that was
included in the cover letter. Namely, that this is not the first such
warning of this kind from SunCC. Or in other words, that we have lots of
static const objects that we depend on being zero'd (and which we can
safely assume _are_ zerod, since they are declared statically), but that
each of them already generates a warning from SunCC.

Mentioning that would give readers an impression of why this was the
only spot touched instead of every static const variable.

But if you take that line of thinking further, I have a hard time
imagining that it's worth fixing small issues like this in piecemeal
when there are already many such warnings. We _could_ fix all of them at
once and amend Documentation/CodingGuidelines, but that seems like a lot
of work for an issue that does not seem to be causing much pain at all.

> 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 };

So this transformation is just fine, but I imagine that we probably
could have just as easily left it alone.

Thanks,
Taylor

  reply	other threads:[~2022-01-11 19:06 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 [this message]
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
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=Yd3VKjvb7AR0/wI9@nand.local \
    --to=me@ttaylorr.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hanwen@google.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.