[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171009183055.567190e7@gandalf.local.home>
Date: Mon, 9 Oct 2017 18:30:55 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Michael Sartain <mikesart@...tmail.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] trace-cmd: Use unsigned values in Hsieh's
trace_hash fast hash function
On Sat, 12 Aug 2017 11:30:46 -0600
Michael Sartain <mikesart@...tmail.com> wrote:
> Signed int values were being used where the original code used uint32_t types:
>
> http://www.azillionmonkeys.com/qed/hash.html
>
> Right shifting negative int values has implementation-defined and left shifting
> has undefined behavior.
>
> On my platform (x86_64) right shifting was doing sign extension and filling
> high bits with 1s, which is different than the original algorithm.
>
Heh, nice catch. Although the hash was never used for anything too
important. Mostly just colors of the graph.
> Signed-off-by: Michael Sartain <mikesart@...tmail.com>
> ---
> trace-hash-local.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/trace-hash-local.h b/trace-hash-local.h
> index b2a1002..b3f9b06 100644
> --- a/trace-hash-local.h
> +++ b/trace-hash-local.h
> @@ -22,7 +22,7 @@
>
> static inline unsigned int trace_hash(int val)
> {
> - int hash, tmp;
> + unsigned int hash, tmp;
>
> hash = 12546869; /* random prime */
>
> @@ -34,7 +34,7 @@ static inline unsigned int trace_hash(int val)
> */
>
> hash += (val & 0xffff);
> - tmp = (val >> 16) ^ hash;
> + tmp = ((unsigned int)val >> 16) ^ hash;
Why not just have val be unsigned int, and not do the typecast?
-- Steve
> hash = (hash << 16) ^ tmp;
> hash += hash >> 11;
>
Powered by blists - more mailing lists