[ 
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)

Reply via email to