| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 09c759bcfa4c2880c571df4da20458b2f781debf.
The reverted patch causes us to not compile functions that we might
not use. In theory this is a good thing. But any competent compiler
is going to exclude them anyway if they aren't used, and we might
miss useful warning messages, or whatnot. See b404539126a for an
example of a patch that would not have happened, or would only
have been partially done had this patch been applied.
Also the reverted patch claimed that "It is not safe to have multiple
hash funcs in 1 build due to conflicts on the size of
PERL_HASH_SEED_BYTES." which is incorrect. The functions do not
reference PERL_HASH_SEED_BYTES directly, and are usable by anyone
who knows what size of seed they need.
Additionally I have on my long-term todo list the following:
* Allow Perl to randomly select the hash function at startup
* Allow Perl to use the hash function determined by the ENV at startup.
This patch would have to be reverted to complete either of those tasks.
To recap, I am reverting this patch because it adds no real value,
makes our hash functions susceptible to bit-rot, and because it blocks
interesting future changes that I plan to work on in the future.
|
| |
|
|
|
|
|
|
|
| |
Perl uses only 1 hash func perl build. It is not safe to have multiple
hash funcs in 1 build due to conflicts on the size of PERL_HASH_SEED_BYTES.
No point in wasting CC's time to compile a static func which will always be
tossed by the CC at the end due to no references to the static has func,
or by the linker due to no references to the funcs. Related to
[perl #123483] .
|
| |
|
|
|
|
|
|
|
| |
These warnings are in a public header, hv_func.h, so CPAN
XS builders will see 8 warnings with every .c file from
a CPAN XS module that they will compile. Silence the
warnings since headers should never warn unconditionally.
See [perl #123483] for details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
