From: Markus Elfring <Markus.Elfring@web.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
kernel@pengutronix.de, kernel-janitors@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>,
linux-spi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
cocci@inria.fr, Amit Dhingra <mechanicalamit@gmail.com>
Subject: Re: [cocci] spi: cadence-xspi: Drop useless assignment to NULL
Date: Tue, 21 Nov 2023 09:51:55 +0100 [thread overview]
Message-ID: <bd627a83-9c9e-451c-a3d6-84e90d40dadd@web.de> (raw)
In-Reply-To: <20231121083246.wg5qtej6cll3snlg@pengutronix.de>
>>>>>>> Static structs are initialized with zeros for unspecified fields.
>>>>>>> So there is no advantage to explicitly initialize .remove with NULL
>>>>>>> and the assignment can be dropped without side effects.
…
> static const struct samsung_pwm_variant s5pc100_variant = {
> .bits = 32,
> - .div_base = 0,
> .has_tint_cstat = true,
> .tclk_mask = BIT(5),
> };
>
> If I saw the resulting code, I'd wonder about the missing assignments
> in these three structs.
How would you get doubts here if you can depend on the well defined initialisation
for unspecified members of static data structure variables?
> So IMHO the status quo is better even though it is more verbose.
Are any design conflicts involved here?
Will the Linux coding style evolve accordingly?
Regards,
Markus
prev parent reply other threads:[~2023-11-21 8:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231105143932.3722920-2-u.kleine-koenig@pengutronix.de>
2023-11-18 16:42 ` [cocci] spi: cadence-xspi: Drop useless assignment to NULL Markus Elfring
[not found] ` <CAO=gReGA17gHSr4ftN1Jwrjt5t76oAgaL6+n6X4wD0osJnuq4g@mail.gmail.com>
2023-11-21 7:34 ` Markus Elfring
[not found] ` <20231121075716.it3cpwhwymkaqjrh@pengutronix.de>
2023-11-21 8:19 ` Markus Elfring
[not found] ` <20231121083246.wg5qtej6cll3snlg@pengutronix.de>
2023-11-21 8:51 ` Markus Elfring [this message]
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=bd627a83-9c9e-451c-a3d6-84e90d40dadd@web.de \
--to=markus.elfring@web.de \
--cc=broonie@kernel.org \
--cc=cocci@inria.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mechanicalamit@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).