Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up[PATCH] It is always safe to delete the most recent key #13650
Comments
From @pjcjCreated by @pjcjIn the perlfunc section on "each" we state: Any insertion If you add or delete a hash's while (($key, $value) = each %hash) { My beef here is with the phrase "In the current implementation". This was We promise unconditionally that deleting the most recent key will not change In addition, the documentation for both "keys" and "values" states: Any insertion So perhaps the attached patch is appropriate. Or have I misunderstood Perl Info |
From @demerphqOn 9 March 2014 15:26, Paul Johnson <perlbug-followup@perl.org> wrote:
No, your understanding is correct, the documentation is not. It is an
You can apply this yourself right? Yves -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @demerphqOn 10 March 2014 08:19, Paul Johnson <paul@pjcj.net> wrote:
Applied as: commit d802114 It is and always will be safe to delete the most recent key -- |
From @pjcjOn Mon, Mar 10, 2014 at 08:13:12AM +0100, demerphq wrote:
Thanks for the confirmation.
No, I don't have a core commit bit. -- |
From @rjbs* "Paul Johnson" (via RT) <perlbug-followup@perl.org> [2014-03-09T10:26:43]
I think that while most of bade7fb seems like great stuff, I agree with you Anyone else? -- |
From @LeontOn Fri, Mar 21, 2014 at 1:45 AM, Ricardo Signes
I'm somewhat worried about ties, but I guess it's not unreasonable to force Leon |
From @nwc10On Fri, Mar 21, 2014 at 10:33:02AM +0100, Leon Timmermans wrote:
I think that it's actually impossible to force ties to support this. I think that we need to a) clarify that this is Perl's hash implementation. Nicholas Clark |
From @demerphqOn 21 March 2014 01:45, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
I think that it is truly binding on all normal perl hashes. Yves -- |
From @tonycozOn Fri Mar 21 02:33:42 2014, LeonT wrote:
How about the attached? Tony |
From @tonycoz0001-perl-121404-tied-hashes-are-different.patchFrom f680130422cd2d8902ffb5569f7c8e10746f47d1 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 24 Jul 2014 17:08:17 +1000
Subject: [PATCH] [perl #121404] tied hashes are different
---
pod/perlfunc.pod | 11 +++++++++--
pod/perlsec.pod | 3 +++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 173615b..ed6f7a8 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1683,6 +1683,9 @@ returned by C<each()>, so the following code works properly:
delete $hash{$key}; # This is safe
}
+Tied hashes may have a different ordering behaviour to perl's hash
+implmentation.
+
This prints out your environment like the printenv(1) program,
but in a different order:
@@ -3155,7 +3158,9 @@ rely on C<keys>, C<values> and C<each> to repeatedly return the same order
as each other. See L<perlsec/"Algorithmic Complexity Attacks"> for
details on why hash order is randomized. Aside from the guarantees
provided here the exact details of Perl's hash algorithm and the hash
-traversal order are subject to change in any release of Perl.
+traversal order are subject to change in any release of Perl. Tied hashes
+may behave differently to Perl's hashes with respect to changes in order on
+insertion and deletion of items.
As a side effect, calling keys() resets the internal iterator of the HASH or
ARRAY (see L</each>). In particular, calling keys() in void context resets
@@ -8747,7 +8752,9 @@ rely on C<keys>, C<values> and C<each> to repeatedly return the same order
as each other. See L<perlsec/"Algorithmic Complexity Attacks"> for
details on why hash order is randomized. Aside from the guarantees
provided here the exact details of Perl's hash algorithm and the hash
-traversal order are subject to change in any release of Perl.
+traversal order are subject to change in any release of Perl. Tied hashes
+may behave differently to Perl's hashes with respect to changes in order on
+insertion and deletion of items.
As a side effect, calling values() resets the HASH or ARRAY's internal
iterator, see L</each>. (In particular, calling values() in void context
diff --git a/pod/perlsec.pod b/pod/perlsec.pod
index 703bd46..b6474e6 100644
--- a/pod/perlsec.pod
+++ b/pod/perlsec.pod
@@ -534,6 +534,9 @@ or the CPAN module C<Algorithm::Numerical::Shuffle>), or for generating
permutations (use e.g. the CPAN modules C<Algorithm::Permute> or
C<Algorithm::FastPermute>), or for any cryptographic applications.
+Tied hashes may have their own ordering and algorithmic complexity
+attacks.
+
=item *
Regular expressions - Perl's regular expression engine is so called NFA
--
1.7.10.4
|
From @demerphqBesides the typo on "implmentation" it looks fine to me. On 24 July 2014 09:11, Tony Cook via RT <perlbug-followup@perl.org> wrote:
-- |
|
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121404 (status was 'resolved')
Searchable as RT121404$