public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Dan Carpenter <error27@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Possible code defects: macros and precedence
Date: Sat, 17 Sep 2016 14:57:52 -0700	[thread overview]
Message-ID: <1474149472.1954.6.camel@perches.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1609172221110.3124@hadrien>

On Sat, 2016-09-17 at 22:24 +0200, Julia Lawall wrote:

(A 2.2MB message that (perhaps thankfully) didn't get through to lkml)

> Below is the Coccinelle output for the case where the definition of the
> macro is a single expression.  There is also the case where it is a
> sequence of statements, but that finds very few results.  Note that
> Coccinelle will only match code that it can parse, which is definitely not
> always the case for macros, so some things may be missed.
> 
> There are a huge number of results.  To the extent that you have the
> patience to look through them, do you see anything undesirable?
> 
> thanks,
> julia
> 
> diff -u -p a/lib/lz4/lz4defs.h b/lib/lz4/lz4defs.h
> --- a/lib/lz4/lz4defs.h
> +++ b/lib/lz4/lz4defs.h
> @@ -34,7 +34,7 @@ typedef struct _U64_S { u64 v; } U64_S;
>  #define PUT8(s, d) (A64(d) = A64(s))
> 
>  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)      \
> -       (d = s - A16(p))
> +       (d = (s) - A16(p))
> 
>  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)        \
>         do {    \
> @@ -53,7 +53,7 @@ typedef struct _U64_S { u64 v; } U64_S;
>         put_unaligned(get_unaligned((const u64 *) s), (u64 *) d)
> 
>  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)      \
> -       (d = s - get_unaligned_le16(p))
> +       (d = (s) - get_unaligned_le16(p))
> 
>  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)                        \
>         do {                                            \

Here's the equivalent checkpatch output for that file.
It has a few more instances.
Is what checkpatch suggests unreasonable?

$ ./scripts/checkpatch.pl -f --strict lib/lz4/lz4defs.h --types=macro_arg_precedence
CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
#36: FILE: lib/lz4/lz4defs.h:36:
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)	\
+	(d = s - A16(p))

CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
#55: FILE: lib/lz4/lz4defs.h:55:
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)	\
+	(d = s - get_unaligned_le16(p))

CHECK: Macro argument 'd' may be better as '(d)' to avoid precedence issues
#106: FILE: lib/lz4/lz4defs.h:106:
+#define LZ4_SECURECOPY(s, d, e)			\
+	do {					\
+		if (d < e) {			\
+			LZ4_WILDCOPY(s, d, e);	\
+		}				\
+	} while (0)

CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
#106: FILE: lib/lz4/lz4defs.h:106:
+#define LZ4_SECURECOPY(s, d, e)			\
+	do {					\
+		if (d < e) {			\
+			LZ4_WILDCOPY(s, d, e);	\
+		}				\
+	} while (0)

CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
#147: FILE: lib/lz4/lz4defs.h:147:
+#define LZ4_WILDCOPY(s, d, e)		\
+	do {				\
+		LZ4_COPYPACKET(s, d);	\
+	} while (d < e)

CHECK: Macro argument 'l' may be better as '(l)' to avoid precedence issues
#152: FILE: lib/lz4/lz4defs.h:152:
+#define LZ4_BLINDCOPY(s, d, l)	\
+	do {	\
+		u8 *e = (d) + l;	\
+		LZ4_WILDCOPY(s, d, e);	\
+		d = e;	\
+	} while (0)

total: 0 errors, 0 warnings, 6 checks, 157 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

lib/lz4/lz4defs.h has style problems, please review.

NOTE: Used message types: MACRO_ARG_PRECEDENCE

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

  parent reply	other threads:[~2016-09-17 21:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-03 18:35 Possible code defects: macros and precedence Joe Perches
2016-09-03 20:18 ` Dan Carpenter
2016-09-03 22:20   ` [PATCH] checkpatch: Add a --strict test for macro argument reuse " Joe Perches
2016-09-04 14:42     ` Joe Perches
2016-09-04 10:10 ` Possible code defects: macros " Julia Lawall
2016-09-04 15:06   ` Joe Perches
     [not found]     ` <alpine.DEB.2.10.1609172221110.3124@hadrien>
2016-09-17 21:27       ` Joe Perches
2016-09-18  5:09         ` Julia Lawall
2016-09-18  9:31           ` Joe Perches
2016-09-20 13:14             ` Julia Lawall
2016-09-20 17:07               ` Joe Perches
2016-09-20 18:03                 ` Joe Perches
2016-09-20 23:47               ` Joe Perches
2016-09-21  5:04                 ` Julia Lawall
2016-09-17 21:57       ` Joe Perches [this message]
2016-09-18  4:57         ` Julia Lawall
2016-09-18  9:27           ` Joe Perches

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=1474149472.1954.6.camel@perches.com \
    --to=joe@perches.com \
    --cc=error27@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=linux-kernel@vger.kernel.org \
    /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