[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3bf931c6ea0cae3e23f3485801986859851b4f04.camel@perches.com>
Date: Sun, 07 Jun 2020 18:02:44 -0700
From: Joe Perches <joe@...ches.com>
To: Yann Collet <cyan@...com>, Vasily Averin <vvs@...tuozzo.com>,
Gao Xiang <hsiangkao@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Gao Xiang <xiang@...nel.org>
Subject: Re: [PATCH] lib/lz4: smatch warning in LZ4_decompress_generic()
On Mon, 2020-06-08 at 00:40 +0000, Yann Collet wrote:
> Hi Vasily
>
>
> If I do understand the discussion, the question is about usage of `&` instead of `&&`,
> and the speculation that it might be an error.
>
> It's not an error. Unfortunately, explaining the reasoning behind this decision is a bit long.
Likely better to add a comment around the use so that
another patch like this doesn't get submitted again.
Perhaps something like:
---
lib/lz4/lz4_decompress.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 0c9d3ad17e0f..5371dab6b481 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -141,6 +141,9 @@ static FORCE_INLINE int LZ4_decompress_generic(
* space in the output for those 18 bytes earlier, upon
* entering the shortcut (in other words, there is a
* combined check for both stages).
+ *
+ * The & in the likely() below is intentionally not && so that
+ * some compilers can produce better parallelized runtime code
*/
if ((endOnInput ? length != RUN_MASK : length <= 8)
/*
Powered by blists - more mailing lists