New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PATCH] fix NO_HASH_SEED build #14956
Comments
From @bulk88Created by @bulk88See attached patch. I also request backporting to 5.18/5.20/5.22. Note Criteria "Patches that fix regressions in perl's behavior relative to Perl Info
|
From @bulk880001-fix-NO_HASH_SEED-build.patchFrom c703dc3cda63554a97a0f0223fe1835651e57ca8 Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Thu, 1 Oct 2015 15:04:29 -0400
Subject: [PATCH] fix NO_HASH_SEED build
commit b1300a738f added PERL_HASH_FUNC_ONE_AT_A_TIME_HARD algo, which was
the first one to introduce 8 byte seeds, previously all the algos used 4
or 16 byte seeds. No case was added to the CPP tree for 8 byte const
seeds, so add one now. Otherwise the #error at the end of the tree runs
and breaks the build. NO_HASH_SEED define was public API in the past and
could be considered to still be public API, see commit f36626324a.
My use for NO_HASH_SEED is reducing entropy for tracking down memory
corruption.
---
hv_func.h | 2 ++
pod/perldelta.pod | 4 +++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hv_func.h b/hv_func.h
index b0e50e3..ce60e53 100644
--- a/hv_func.h
+++ b/hv_func.h
@@ -84,6 +84,8 @@
# define PERL_HASH_SEED PL_hash_seed
# elif PERL_HASH_SEED_BYTES == 4
# define PERL_HASH_SEED "PeRl"
+# elif PERL_HASH_SEED_BYTES == 8
+# define PERL_HASH_SEED "PeRlHaSh"
# elif PERL_HASH_SEED_BYTES == 16
# define PERL_HASH_SEED "PeRlHaShhAcKpErl"
# else
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index a5e7055..caa6067 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -240,7 +240,9 @@ L</Platform Support> section, instead.
=item *
-XXX
+Using the C<NO_HASH_SEED> define in combination with the default hash algorithm
+C<PERL_HASH_FUNC_ONE_AT_A_TIME_HARD> resulted in a fatal error while compiling
+the interpreter, since 5.17.10. This has been fixed.
=back
--
1.7.9.msysgit.0
|
From @tonycozOn Thu Oct 01 12:13:53 2015, bulk88 wrote:
Thanks, this patch doesn't fix another problem with the -DNO_HASH_SEED build - the hash functions expect an unsigned char *, but C/C++ strings have type const char *, so we see a large number of warnings on C[1], and build failures on C++. Would you like to produce an updated patch, or leave it to me to fix? Tony [1] it's incorrect in C too, many compilers forgive it though |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Mon Oct 12 15:43:21 2015, tonyc wrote:
You fix it. It will take a week or a couple weeks for me to get the opportunity to revise the patch and it is easier if you fix it and close this ticket. -- |
From @tonycozOn Thu Oct 01 12:13:53 2015, bulk88 wrote:
Thanks, applied as c2d4ebc, with the char * vs unsigned char * fix in 25c1b13.
I haven't seen a volunteer though.
I'd added a note to #123362 and added both patches to the 5.20 and 5.22 votes files. Tony |
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#126242 (status was 'resolved')
Searchable as RT126242$
The text was updated successfully, but these errors were encountered: