Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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

by BrowserUk (Pope)
on Nov 29, 2012 at 13:07 UTC ( #1006246=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^2: Hash order randomization is coming, are you ready?
Re^3: Hash order randomization is coming, are you ready?
by Anonymous Monk on Nov 29, 2012 at 13:39 UTC
      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

        It has always been the case. Keys are returned in bucket order, then top to bottom. Keys that collide into the same bucket will be stored in LIFO order. When copying a hash like so:

        %copy= %orig;

        %copy will be identical to %orig only if the the size of the bucket array is the same and no buckets collide. If the size of the bucket array is different the key order will change.

        $ ./perl -Ilib -MHash::Util=bucket_array -MData::Dumper -le'my (%hash, +%copy); keys(%copy)=16; %hash=(1..14); %copy=%hash; print Data::Dumpe +r->new([bucket_array($_)])->Terse(1)->Indent(0)->Dump for \%hash, \%c +opy;' [['13','5'],1,['7'],['11'],2,['3','1'],['9']] [3,['11'],3,['9'],['5','13'],1,['7'],3,['1','3'],1]

        Even if the bucket size is the same if items collide then during the copy they will reverse order relative to each other.

        $ ./perl -Ilib -MHash::Util=bucket_array -MData::Dumper -le'my (%hash, +%copy); %hash=(1..14); %copy=%hash; print Data::Dumper->new([bucket_a +rray($_)])->Terse(1)->Indent(0)->Dump for \%hash, \%copy;' [['11'],['7'],2,['13','5'],['9','3'],['1'],1] [['11'],['7'],2,['5','13'],['3','9'],['1'],1]

        None of this is new. The only new thing that changes here is which keys collide, and the fact that for a given list of keys, with hash randomization eventually they will all collide with each other. Before if you were lucky and your keys didn't collide, such as in tests, then broken code might work. At least until some new key was added that changed the state of the hash.

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

Re^3: Hash order randomization is coming, are you ready?
by mje (Curate) on Nov 29, 2012 at 17:11 UTC

    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

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

    No, this has not changed.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (8)
As of 2014-10-20 23:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (92 votes), past polls