in reply to Re: Compression in Golf: Part III
in thread Compression in Golf: Part III
To help the casual reader appreciate the depths of depravity and deviousness of dmd's solution, consider this snippet:
For this to work:
j x 165^pack$<^C,'packed-string'
That is, like many winning codegolf solutions, this one hangs by a thread.
- Perl must interpret $< (aka $UID) as a string, not a number, otherwise the xor with "C" will not produce the desired "u" for pack's first parameter.
- The $< special variable must be greater than or equal to 1123 because 123 is the length of the compressed string. This special variable seems to take the value 65534 on the codegolf server, so the string produced by $<^C there is "u5534".
- dmd was undeterred by "u5534" being way out of range for pack. On the contrary, this turned out to be an opportunity because perl 5.8 has a nasty memory bug (fixed in later perl versions, as mentioned in Compression in Golf: Part I) so that going beyond "u63" essentially results in a random value for the length byte, depending on what happens to be in the memory being read beyond the end of the PL_uudmap array. That is, this solution works with the perl 5.8.8 running on the codegolf server but fails with later perl versions and may even fail with perl 5.8 running in a different environment.
- The random value dmd got in the first position as pack's length byte on the codegolf server happened to be "f" which he was able to exploit by xor'ing with "j" to produce form-feed (ord 12) as the leading character, so as not to muck up the program string to be eval'ed (as a leading "f" would have done). By the way, if you could somehow fluke a leading "s" or "@" for the length byte you may be able to shave another stroke because short solutions to the bottle golf typically start with "s" or "@".
With the right timing x 165 can be replaced by x$$, saving two strokes
Now that's just sick.
If you managed to submit your entry at just the right time when $$
took the value 165 on the codegolf server, I salute you!
This reminds me of some of the antics described in the
"Outsmarting the Robot Referee" section at The golf course looks great, my swing feels good, I like my chances (Part IV)
where entries were submitted when the $^T time variable
took just the right value on the codegolf server.
Thanks for sharing your solution.
I find it hilarious that when we were tied for the lead
at 151 strokes, we both probably assumed we had similar solutions,
when, in fact, they were completely different. :)