Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Hash order randomization is coming, are you ready?

by chrestomanci (Priest)
on Nov 29, 2012 at 12:53 UTC ( [id://1006244]=note: print w/replies, xml ) Need Help??


in reply to Hash order randomization is coming, are you ready?

Will the order of keys returned change from one call to the next on the same has in the same run of a script? Is there an explicit shuffle done every time you call keys etc?

Consider the code:

my $hashRef = someFuncCall(); my $keys1 = join(' ', keys %$hashRef); my $keys2 = join(' ', keys %$hashRef); print "Key order is not stable" if $keys1 ne $keys2;

Replies are listed 'Best First'.
Re^2: Hash order randomization is coming, are you ready?
by BrowserUk (Patriarch) on Nov 29, 2012 at 13:07 UTC

    One certainly hopes they haven't broken one of the few guarantees given in the POD:

    keys HASH

    Returns a list consisting of all the keys of the named hash. (In scalar context, returns the number of keys.)

    The keys are returned in an apparently random order. The actual random order is subject to change in future versions of perl, but it is guaranteed to be the same order as either the values or each function produces (given that the hash has not been modified). Since Perl 5.8.1 the ordering is different even between different runs of Perl for security reasons (see Algorithmic Complexity Attacks in the perlsec manpage).

    Then again, it would have been useful to jave been told how this new randomisation varies from that which has been in place since 5.8.1?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    RIP Neil Armstrong

      A casual test looks like that statement is still true:

      use 5.17.6; use strict; use warnings; my %a = ( z => 1, y => 2, x => 3); foreach (1..3) { print join(",", keys %a), "\n"; print join(",", values %a), "\n"; while (my ($d,$e) = each %a) { print "$d = $e\n"; } }

      run 1

      z,y,x 1,2,3 z = 1 y = 2 x = 3 z,y,x 1,2,3 z = 1 y = 2 x = 3 z,y,x 1,2,3 z = 1 y = 2 x = 3

      run 2

      x,y,z 3,2,1 x = 3 y = 2 z = 1 x,y,z 3,2,1 x = 3 y = 2 z = 1 x,y,z 3,2,1 x = 3 y = 2 z = 1

        Yes indeed. This cannot change. And is guaranteed by the nature of the how keys() and values() are implemented in native hashes (non-magical). Basically they are both achieved by walking the bucket array from left to right and within a bucket from top to bottom. Since they both do the same data structure walk they both return the same results. However note this is true only of a /given/ hash. You can't assume that one hashes keys() will match another's values() even if they contain the same list of keys().

        ---
        $world=~s/war/peace/g

      No, this has not changed.

      ---
      $world=~s/war/peace/g

        two identical hashes don't produce the same keys/values order

        I wonder about the justifiction for that? Not just fiddling for the sake of it I hope :(


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        RIP Neil Armstrong

Re^2: Hash order randomization is coming, are you ready?
by demerphq (Chancellor) on Dec 02, 2012 at 11:17 UTC

    Since we have to maintain the same order between values() and keys() I do not think that we can change this. However IMO you should not depend on it.

    ---
    $world=~s/war/peace/g

      Maintaining the same order between values and keys should mean you can depend on keys returning the same order each time, otherwise how is values supposed to know which order to present its order?

      my @keys1 = keys %some_hash; my @keys2 = keys %some_hash; #different from @keys1? my @values = values %some_hash; # same order as @keys1 or same as @key +s2?
      That makes it look pretty dependable to me, assuming: a) same process (or a fork of it), and b) hash otherwise unchanged between the two calls to keys.

      Personally, I only rely on the order when I'm doing something like @hash2{keys %hash1} = values %hash1;, otherwise I don't think I ever rely on the order from keys (if I care, I sort them) or values (there's no real way to sort values the same as sorting keys anyway), so I doubt I'm affected, but only one way to find out. :-)

        otherwise how is values supposed to know which order to present its order?

        That is the question really. :-) If it is possible then it might be done. I wouldn't assume its impossible, even though I think it is likely to be impossible.

        ---
        $world=~s/war/peace/g

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1006244]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-03-29 15:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found