From: Michael Witten <mfwitten@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Cong Wang <xiyou.wangcong@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Sam Ravnborg <sam@ravnborg.org>,
linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'
Date: Mon, 17 Aug 2020 03:37:00 -0000 [thread overview]
Message-ID: <23e2e6c2d3a24954bccb67a3186019b9@gmail.com> (raw)
In-Reply-To: <61f8da080e5fac1bc23cdd68c43f199029c0a788.camel@perches.com>
Joe Perches (Sun, 16 Aug 2020 10:56:53 -0700):
> I rather prefer block declarations instead of
> sprinkling declarations around with code.
Hey, we all have our guilty pleasures.
Fortunately, even with this patch, you'd still be able to indulge
in your preferred style, or even enforce it among contributors to
the code that you maintain.
However, the following statement should hold:
If merged code is correct (portable, safe, etc.),
then the kernel must build without any warning
about that merged code.
Sometimes, code is clearest (or indeed safest) when it is written
with a variable definition that occurs at a point well within the
body of statements. Authors need to have the option to write such
code; otherwise, style ceases to be means of clarity, and instead
becomes a laborious end unto itself.
Matters of style should probably not be enforced by the build
infrastructure; style is a matter for the maintainer to enforce:
* Perhaps there could be a new build-time switch. By default,
the warning can be off for a normal build; a maintainer can
flip the switch to turn it on locally, and thereby check
whether a patch declares variables unnecessarily hither and
thither, as determined by the maintainer's taste.
* Perhaps `scripts/checkpatch.pl' could be taught about this
issue. Though probably easier said than done, the script
could parse every modified block, and warn about declarations
after statements (but maybe ignore the declarations that
introduce const variables).
* Perhaps there is already linting infrastructure that could be
put to such use.
This way, good code can compile cleanly, and style can just be an
ongoing topic of discussion among contributors.
Sincerely,
Michael Witten
next prev parent reply other threads:[~2020-08-17 3:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-16 16:35 [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement' Michael Witten
2020-08-16 17:53 ` Al Viro
2020-08-17 20:42 ` Pavel Machek
2020-08-17 21:12 ` Eric W. Biederman
2020-08-17 21:29 ` Linus Torvalds
2020-08-17 22:09 ` Pavel Machek
2020-08-17 22:12 ` Linus Torvalds
2020-08-18 5:17 ` Ingo Molnar
2020-08-18 8:56 ` David Laight
2020-08-16 17:56 ` Joe Perches
2020-08-17 3:37 ` Michael Witten [this message]
2020-08-17 4:19 ` Joe Perches
2020-08-17 11:40 ` Michael Witten
2020-08-17 20:38 ` Pavel Machek
2020-08-18 22:05 ` Michael Witten
2020-08-19 21:15 ` Michael Witten
2020-08-20 0:15 ` [RFC v2] kbuild: Introduce "Warnings for maintainers" Michael Witten
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=23e2e6c2d3a24954bccb67a3186019b9@gmail.com \
--to=mfwitten@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=joe@perches.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=sam@ravnborg.org \
--cc=xiyou.wangcong@gmail.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 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 NNTP newsgroup(s).