From: Tom Rix <trix@redhat.com>
To: Joe Perches <joe@perches.com>,
Sebastian Gottschall <s.gottschall@newmedia-net.de>,
John Crispin <john@phrozen.org>,
toke@toke.dk, kvalo@kernel.org, davem@davemloft.net,
kuba@kernel.org, pabeni@redhat.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath9k: initialize arrays at compile time
Date: Wed, 23 Mar 2022 06:13:25 -0700 [thread overview]
Message-ID: <c290ae27-9e4a-96ed-d8d6-a8b8bf8d0181@redhat.com> (raw)
In-Reply-To: <7a12fd4599758b8cd5fd376db6c9a950d2ed2094.camel@perches.com>
On 3/20/22 10:36 AM, Joe Perches wrote:
> On Sun, 2022-03-20 at 18:17 +0100, Sebastian Gottschall wrote:
>> Am 20.03.2022 um 17:48 schrieb John Crispin:
>>>
>>> On 20.03.22 16:20, trix@redhat.com wrote:
>>>> array[size] = { 0 };
>>> should this not be array[size] = { }; ?!
>>>
>>> If I recall correctly { 0 } will only set the first element of the
>>> struct/array to 0 and leave random data in all others elements
>>>
>>> John
>> You are right, john
> No. The patch is fine.
>
> Though generally the newer code in the kernel uses
>
> type dec[size] = {};
>
> to initialize stack arrays.
>
> array stack declarations not using 0
>
> $ git grep -P '^\t(?:\w++\s*){1,2}\[\s*\w+\s*\]\s*=\s*\{\s*\};' -- '*.c' | wc -l
> 213
>
> array stack declarations using 0
>
> $ git grep -P '^\t(?:\w++\s*){1,2}\[\s*\w+\s*\]\s*=\s*\{\s*0\s*\};' -- '*.c' | wc -l
> 776
>
> Refer to the c standard section on initialization 6.7.8 subsections 19 and 21
>
> 19
>
> The initialization shall occur in initializer list order, each initializer provided for a
> particular subobject overriding any previously listed initializer for the same subobject
> all subobjects that are not initialized explicitly shall be initialized implicitly the same as
> objects that have static storage duration.
>
> ...
>
> 21
>
> If there are fewer initializers in a brace-enclosed list than there are elements or members
> of an aggregate, or fewer characters in a string literal used to initialize an array of known
> size than there are elements in the array, the remainder of the aggregate shall be
> initialized implicitly the same as objects that have static storage duration.
>
Joe,
Thanks for providing these sections for c reference !
I will update the commit log and replace { 0 } with { }
Tom
next prev parent reply other threads:[~2022-03-23 13:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-20 15:20 trix
2022-03-20 16:16 ` Joe Perches
2022-03-20 16:48 ` John Crispin
2022-03-20 17:17 ` Sebastian Gottschall
2022-03-20 17:36 ` Joe Perches
2022-03-23 13:13 ` Tom Rix [this message]
2022-03-20 17:32 ` Andreas Schwab
2022-03-20 18:46 ` David Laight
2022-03-21 13:31 ` Toke Høiland-Jørgensen
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=c290ae27-9e4a-96ed-d8d6-a8b8bf8d0181@redhat.com \
--to=trix@redhat.com \
--cc=davem@davemloft.net \
--cc=joe@perches.com \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=s.gottschall@newmedia-net.de \
--cc=toke@toke.dk \
/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
all inboxes | Powered by JetHome®