The IOCCC is back! I think this will be the year I enter. Here's my concept...

The C program will interpret a simple function-combinator language. The first catch: the names of the functions that the interpreter is composing will be cryptographically hashed with UNIX crypt(3). To figure out what it's supposed to be doing, it'll perform a dictionary attack against itself using the list of installed manpages as a dictionary. When it finds a match, it'll look up and call the function using dlopen(3)/dlsym(3).

As is common for IOCCC entries, none of the library functions being called will appear in the C code by their correct names. But rather than the traditional boring approach of using #define to obfuscate them, I'll link against modified libraries generated using objcopy(1) --redefine-syms, so that, e.g., dlsym() is now named fprintf().

Furthermore, the string being interpreted will be declared extern by the code, with its actual definition found nowhere within. This will be resolved by more objcopy abuse. If you look at the program's build script, you'll see it heavily commented with a bunch of rambling, marginally coherent prose. Run the script through 'objcopy -I binary -O default -i 12' (grabbing every 12th byte) and the result will be an object file providing the string.

The behavior of the program will be to output a Postscript program and then invoke gs(1) on it; functions in the Postscript program will be named after random substrings taken from the combinator code.

And what will the Postscript program do? I haven't decided yet. I'm leaning toward having it be a type-checker/interpreter for an obfuscated dialect of the Calculus of Constructions.
Shared publiclyView activity