I was wondering how the hash thing worked. Got my answer from the notes, which are otherwise hilarious.
"While terseness was preferred over obscurity, this program hopefully still lives down to IOCCC’s usual standards of clarity."
I was wondering how the hash thing worked. Got my answer from the notes, which are otherwise hilarious.
"While terseness was preferred over obscurity, this program hopefully still lives down to IOCCC’s usual standards of clarity."
Also:
“Several variants of this program were considered. Several.”
(They must have tried billions of variants to find the match on md5sum. Luckily, you don’t have to compile or run the code to find that match)
Since 2009, it has not been that hard to create a collision (where you control both inputs and only care that they end up with the same hash as each other). https://archive.org/details/pocorgtfo14/page/n45/mode/1up After reading this article, scroll up to the top and see that the PDF has its own MD5 hash on the cover.
Or this gif that animates its own MD5sum: https://shells.aachen.ccc.de/~spq/md5.gif
I was mostly interested if the solution did that or calculated its own hash on the fly, for example by reading its own source. Thinking about it and considering how short the source is it must have been the former all along, but that was my motivation looking into the notes. I didn't regret it.
This isn’t (fully) a situation where you control both inputs. The MD5 hash code has to be a ‘program’ that produces a nice icon when processed by the program whose MD5 hash code has that value.