Cody Boone Ferguson
009e1b7522
The location of the link is in the About menu under the 'Contacting the IOCCC' and above 'Thanks for the help'. At first I had it at the very bottom, under 'IOCCC markdown guidelines', but it seemed better to have it closer to contacting the IOCCC. This is the same location in the no JavaScript menu (which, for those who do not know or forget, is not a requirement except for some screen sizes). The top level Makefile has a new 'security' rule. Updated make help. Typo fixes in make help. SECURITY.html has had a few updates as well: change the wording of entry code is unsupported (it now says 'ALL CODE IN ALL IOCCC ENTRIES IS UNSUPPORTED!!') and it now links to the mkiocccentry repo and how to report a possible security vulnerability in that repo; as that IS supported - and since there was reference to discussing security concerns is in SECURITY.html - even though the entries will not receive security updates - it seemed a good idea to have a link to report such security issues in the mkiocccentry repo. Perhaps the FAQ needs to be updated for this too.
Twenty Second International Obfuscated C Code Contest
Standard IOCCC stuff
View the index.html web page for the given winning entry for information on how
compile the entry and how to run the winning program. Look at the winning
source and try to figure how it does what it does! You may then wish to look at
the Author's remarks for even more details.
Some ANSI C compilers are not quite as good as they should be. If yours is lacking, you may need to compile using gcc instead of your local compiler.
The IOCCC has a website and now has a number of international mirrors. The primary website can be found at www.ioccc.org.
Remarks on some of the entries
We believe you will again be impressed with this year's winning entries.
This year, 9 won 15 awards. For the first time in the history of the contest, one person, Yusuke Endoh won 4 times while Adrian Cable won 3 times! It is also worth noting that Chris Mills' last win was in 1993. Welcome back Chris!
We, the judges, were very surprised by this as many of the multiple authors submitted very different styles of entries.
This year was the first time the IOCCC size tool was used. Entries
had to print a value 2053 or less when the -i flag was used.
Several people discovered an undocumented feature in that certain comments such as:
///*
or:
*\
/
were not correctly parsed by the tool. The guidelines stated:
In cases where the above summary and the algorithm implemented by the IOCCC size tool source code conflict, the algorithm implemented by the IOCCC size tool source code is preferred by the judges.
... so this abuse was allowed (and encouraged). The judges hope that the IOCCC size tool author will patch the tool to block this kind of size abuse in future contests.
There were some outstanding entries that did not win. Unfortunately some very good entries lost because they:
- were way way oversized and didn't even attempt to justify their excess by a clever abuse of the rules
- depended on a single obfuscation trick
- could only be run on a particular vendor's platform
- were very similar to previous winning entry
- didn't work as documented
We hope that the authors of some of those entries will fix and resubmit them for the next IOCCC.
There is a risk in submitting an entry that is similar to a well used theme by previous winning entries. Previous entries set a very high bar. A new entry must not only compete against other submissions from the current year but they must also excel over similar previous winning entry in some particularly impressive way.
Final Comments
IMPORTANT NOTE: See contact.html for up to date contact details as well as details on how to provide fixes to any of the entries. See also the IOCCC FAQ for additional information on the IOCCC.