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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.