| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Both of these hash functions are by Austin Appleby and are in the public domain.
The 64A variant is designed for 64 bit machines.
The 64B variant is designed for 32 bit machines.
Both use unaligned loads, so are unsuitable for platforms with strict alignment requirements.
Both have been converted to use Perls hash function calling conventions,
and to return a 32 bit hash instead of a 64 bit hash (low 32 bits)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a previous commit I added code to "mix in" the length of the
string into the seed used by these functions, to avoid issues with
zero seeds, and with the hope that it makes it harder to create
multicollision attacks against these hash functions.
Unfortunately when I restructured the seed logic for the inline
functions in hv_func.h I messed it up, and these hash functions
were broken. I never noticed because they are both such bad hash
functions for our needs that I never built with them, and we have
no infrastructure to make it easy to test building with non-standard
hash functions so it never got automatically tested. Hopefully
at some point someone will find a round-tuit and teach Configure
about selecting alternate hash functions.
|
| | |
|
| |
|
|
| |
Support for __BORLANDC__ was axed (actually, chainsawed) in 378eeda70c.
|
| |
|
|
|
|
|
|
| |
Seeing 3 hash algos with the same name is confusing. If they are the same
name ("one at a time"), then why are there 3 different ones? What are the
differences (without reading the code)? What are the pros and cons of each?
INSTALL lists the ONE_AT_A_TIME algos as existing, but doesn't explain why
there are 3 of them. Patch with jkeenan suggestions.
|
| |
|
|
|
|
| |
Install was a copy of other material, made heavy reference to 5.8.x and
and didnt really document what it should have. I reworked it to be more
up to date.
|
| |
|
|
|
|
|
|
|
|
|
| |
The cast to IV was added to avoid problems on platforms where pointers are
larger than longs. However, the change instead generates warnings on
platforms where IVs are larger than pointers. Instead, use the PTR2IV()
macro provided by perl.h to make everyone happy.
Also change the type of the variable on that line, because it is cast to
STRLEN the first time it is used, and then passed to a macro that assigns it
to an int regardless.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by "Sisyphus"
# Please include the string: [perl #117687]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117687 >
This is a bug report for perl from sisyphus@OWNER-PC311012,
generated with the help of perlbug 1.39 running under perl 5.17.11.
-----------------------------------------------------------------
[Please describe your issue here]
This is essentially a repeat of a post sent to p5p on March 24 2013
titled "[Win32] perl-5.17.10 fails to build with x64 mingw64 (gcc-4.7.0)"
The issue still exists for 5.17.11 (for me).
The error I get is:
In file included from ../hv.h:570:0,
from ../perl.h:3480,
from perllib.c:10:
../hv_func.h: In function 'U32 S_perl_hash_murmur3(const unsigned char*,
const u
nsigned char*, STRLEN)':
../hv_func.h:395:20: error: cast from 'const unsigned char*' to 'long int'
loses
precision [-fpermissive]
Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
|
| | |
|
| |
|
|
| |
For testing, but maybe for ever
|
| |
|
|
| |
as far as I can tell 'i' can only be positive here.
|
| |
|
|
| |
Mix in additional randomness into the final value.
|
|
|
This includes various tweaks related to building SipHash and other
cleanup.
|
