Shared publicly  - 
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.
International Obfuscated C Code Contest
Ken Burnside's profile photoDaniel Franke's profile photoPatrick Maupin's profile photo
Sounds interesting. But do the rules allow all the external-to-C system abuse you're describing?

I seem to remember previous IOCCC entries working just fine on any OS...
The guidelines discourage code that isn't portable across different POSIX systems, as well as the use the build file to circumvent the size limit. But, programs that abuse these two guidelines in much worse ways have won many times before. Mind you, I'm not actually generating any C code, just data. So what if the data happens to be Turing-complete? :-)
Be sure to write all comments in the code in a highly allusional poetic form, preferably with Norse-style alliteration. Then run it through ROT-13.
Ooooh! New idea: I'll obtain the nonsense prose by grepping my spam folder for strings that fit.
Add a comment...