in reply to Re: Re: Bite Buckets JAPH
in thread Byte Buckets JAPH

And to further confirm that it's only working on 5.8.0, it doesn't work on 5.8.1 either ;-)

Liz

Update:
With the environment variable PERL_HASH_SEED set to 0, the output is indeed "JUST ANOTHER PERL HACKER". If set to another value, it is always the same, but definitely not Just Another Perl Hacker. Without the environment variable set, the output is different each time you run it.

Since I can't refer to the new documentation of "perlrun" on perldoc.com, I'll just pit it here for those of you who are interested:

PERL_HASH_SEED
(Since Perl 5.8.1.) Used to randomise Perl's internal hash function. To emulate the pre-5.8.1 behaviour, set to an integer (zero means exactly the same order as 5.8.0). "Pre-5.8.1" means, among other things, that hash keys will be ordered the same between different runs of Perl. The default behaviour is to randomise unless the PERL_HASH_SEED is set. If Perl has been compiled with "-DUSE_HASH_SEED_EXPLICIT", the default behaviour is not to randomise unless the PERL_HASH_SEED is set. If PERL_HASH_SEED is unset or set to a non- numeric string, Perl uses the pseudorandom seed supplied by the operating system and libraries. This means that each different run of Perl will have a different ordering of the results of keys(), values(), and each(). See "Algorithmic Complexity Attacks" in perlsec for more information.

PERL_HASH_SEED_DEBUG
(Since Perl 5.8.1.) Set to "1" to display (to STDERR) the value of the hash seed at the beginning of execution.

FInally, setting $ENV{PERL_HASH_SEED}=0 during execution does not have the desired effect: the environment variable is checked during startup of Perl, looong before you can set Perl's copy of the environment variable.

Replies are listed 'Best First'.
Re: Re: Re: Re: Bite Buckets JAPH
by Limbic~Region (Chancellor) on Sep 06, 2003 at 15:34 UTC
    liz,
    Not having 5.8.1 handy, I would be interested in seeing if the compile time option in reference to hashes makes a difference in how this works. I believe there is a way to "restore" the 5.8.0 way hashes work from what I have heard?

    If I have guessed correctly as to the nature of the JAPH, it is highly unlikely that it would be possible to make the JAPH version independent without increasing quite a bit of the code.

    Cheers - L~R

[reply]
      Anyone reading this far into the thread deserves the JAPH explanation (and probably already understands it anyway).

      The JAPH relies on the less-known and seldom-used fact that evaluating an entire hash (%hash) in scalar context returns a pair of numbers expressed as a fraction, as in "7/16", meaning seven buckets used, sixteen buckets allocated.

      In developing the JAPH, I ran a quick c-style for loop to populate a hash with unique small integer keys and null string values. As each key/value was added, I printed the iteration number and the bucket info. I then used that data as a crossreference to see how many keys of these small integers had to be created before I would get to, for example, 32 buckets in use (I didn't care about the total allocated). Earlier I had been surprised to find it's not a direct 1:1 keys to buckets ratio. 32 buckets could be used to represent the ordinal value 32, which could be used to represent the ascii value of " " (space). The regexp simply pulls out the first value (buckets used) and doesn't bother with the second value (buckets allocated).

      As I began coding the JAPH, I simply used a loop to perform the same population technique, but rather than print the results, I just used the results to drive the translation into ASCII values.

      Next, I came up with a space-saving algorithm that read the ord number, and then any following comma-delimited integers, which would specify the position within an array where that particular character should be inserted. For example, "32 4,12" would mean stick chr(32) in the 5th and 13th element (zero-indexed, of course) of the array. Once the array is populated, print it.

      It surprises me that Liz's method of setting the ENV variable related to hashes to zero would make 5.8.1 work ok with this methodology. My understanding was that env variable dealt with the order of key/value pairs. This JAPH doesn't rely on the order as much as it relies on the allocation and use of space. But nevertheless, if her method works, I'm pleased to hear it. And am pleased that anyone would take the time to figure out the kludge to my kludge. I'm nearly equally surprised that the JAPH worked in the first place, and especially so, across OS platforms. I figured that it would be more difficult than it was to assure repeatability across OS platforms.

      Dave

      "If I had my life to do over again, I'd be a plumber." -- Albert Einstein

[reply]

In Section Obfuscated Code