[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23e2e6c2d3a24954bccb67a3186019b9@gmail.com>
Date: Mon, 17 Aug 2020 03:37:00 -0000
From: Michael Witten <mfwitten@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Cong Wang <xiyou.wangcong@...il.com>,
Johannes Weiner <hannes@...xchg.org>,
Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'
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
Powered by blists - more mailing lists