From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH 6/6] checkpatch.pl: Request if() instead #ifdef
Date: Mon, 15 Jun 2020 11:58:57 +0900 [thread overview]
Message-ID: <20200615025857.GA20498@laputa> (raw)
In-Reply-To: <20200604233935.GO32287@bill-the-cat>
On Thu, Jun 04, 2020 at 07:39:35PM -0400, Tom Rini wrote:
> On Fri, May 22, 2020 at 04:32:40PM -0600, Simon Glass wrote:
>
> > There is a lot of use of #ifdefs in U-Boot. In an effort reduce this,
> > suggest using the compile-time construct.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>
> Applied to u-boot/master, thanks!
This check is simple, but IMHO, too simple.
It will generate false-positive, or pointless, warnings
for some common use cases. Say,
In an include header,
#ifdef CONFIG_xxx
extern int foo_data;
int foo(void);
#endif
Or in a C file (foo_common.c),
#ifdef CONFIG_xxx_a
int foo_a(void)
...
#endif
#ifdef CONFIG_xxx_b
int foo_b(void)
...
#endif
Or,
struct baa baa_list[] = {
#ifdef CONFIG_xxx
data_xxx,
#endif
...
They are harmless and can be ignored, but also annoying.
Can you sophisticate this check?
In addition, if I want to stick to this rule, there can co-exist
an "old" style and "new" style of code in a single file.
(particularly tons of examples in UEFI subsystem)
How should we deal with this?
Thanks,
-Takahiro Akashi
> --
> Tom
next prev parent reply other threads:[~2020-06-15 2:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 22:32 [PATCH 0/6] checkpatch.pl: Add features to help improve U-Boot code Simon Glass
2020-05-22 22:32 ` [PATCH 1/6] checkpatch.pl: Update to v5.7-rc6 Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-05-22 22:32 ` [PATCH 2/6] checkpatch.pl: Add a U-Boot option Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-05-22 22:32 ` [PATCH 3/6] checkpatch.pl: Add a check for tests needed for uclasses Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-05-22 22:32 ` [PATCH 4/6] checkpatch.pl: Warn if the flattree API is used Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-05-22 22:32 ` [PATCH 5/6] checkpatch.pl: Request a test when a new command is added Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-05-22 22:32 ` [PATCH 6/6] checkpatch.pl: Request if() instead #ifdef Simon Glass
2020-06-04 23:39 ` Tom Rini
2020-06-15 2:58 ` AKASHI Takahiro [this message]
2020-06-15 3:58 ` Simon Glass
2020-06-15 14:34 ` Tom Rini
2020-06-16 0:34 ` AKASHI Takahiro
2020-06-16 1:21 ` Tom Rini
2020-06-16 2:15 ` Simon Glass
2020-05-24 18:23 ` [PATCH 0/6] checkpatch.pl: Add features to help improve U-Boot code Tom Rini
2020-05-26 18:29 ` [PATCHv2] checkpatch.pl: Add check for defining CONFIG_CMD_xxx via config files Tom Rini
2020-06-04 23:39 ` Tom Rini
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=20200615025857.GA20498@laputa \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.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