develooper Front page | perl.perl5.porters | Postings from July 2014

Re: [perl #121404] [PATCH] It is always safe to delete the mostrecent key

Thread Previous
From:
demerphq
Date:
July 24, 2014 07:19
Subject:
Re: [perl #121404] [PATCH] It is always safe to delete the mostrecent key
Message ID:
CANgJU+VKrrRh9STobpnwfZzWs9_cae7-o94CdRvstrFLF3xRNQ@mail.gmail.com
Besides the typo on "implmentation" it looks fine to me.


On 24 July 2014 09:11, Tony Cook via RT <perlbug-followup@perl.org> wrote:

> On Fri Mar 21 02:33:42 2014, LeonT wrote:
> > On Fri, Mar 21, 2014 at 1:45 AM, Ricardo Signes
> > <perl.p5p@rjbs.manxome.org>wrote:
> >
> > > * "Paul Johnson" (via RT) <perlbug-followup@perl.org>
> > > [2014-03-09T10:26:43]
> > > > We promise unconditionally that deleting the most recent key will
> > > > not
> > > change
> > > > the iteration order, then we weaken that promise.  But are we
> > > > really
> > > thinking
> > > > that the above code may one day be illegal?  We had promised it
> > > > would
> > > always
> > > > be safe since 2000 (74fc8b5).
> > >
> > > I think that while most of bade7fb seems like great stuff, I agree
> > > with you
> > > here.  This promise seems like one we want to consider truly binding.
> > >
> > > Anyone else?
> > >
> >
> > I'm somewhat worried about ties, but I guess it's not unreasonable to
> > force
> > them to support this too.
>
> How about the attached?
>
> Tony
>
> ---
> via perlbug:  queue: perl5 status: open
> https://rt.perl.org/Ticket/Display.html?id=121404
>
> From 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
>
>
>


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About