[jira] [Commented] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument

["Alex Herbert (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979255#comment-16979255 ] 

Alex Herbert commented on CODEC-264:
------------------------------------

As discussed on the PR raised by Claude the two sign extension bugs in MurmurHash3 should be fixed in new methods to avoid behavioural changes to the existing released hash32 and hash128 methods.

New methods can take inspiration from the c++ source code method names:
{noformat}
MurmurHash3_x86_32 -> MurmurHash3.hash32x86
MurmurHash3_x64_128 -> MurmurHash3.hash128x64
{noformat}


> murmur3.hash128() does not account for unsigned seed argument
> -------------------------------------------------------------
>
>                 Key: CODEC-264
>                 URL: https://issues.apache.org/jira/browse/CODEC-264
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.13
>            Reporter: Claude Warren
>            Assignee: Alex Herbert
>            Priority: Major
>         Attachments: YonikMurmur3Tests.java
>
>
> The original murmur3_x64_128 code used unsigned int for seed arguments.  Using the equivalent bit patterns in the commons codec version does not yield the same results.
> I believe this is because the commons version does not account for sign extension etc.
> Yonic Seeley [~yonik] has explains the issue in his implementation https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java
> He provides a test case to show that his code returns the same answers as the original C/C++ code.  I modified that test to call the codec version to show the error.
> I have attached that test case.
> Given that the original code is in the wild I am uncertain how to fix this issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)