In other words rather than have the link name in the form of:
1984 decot bugs
it is now:
1984/decot in bugs.html
so that it matches how the entry itself looks (as in how it's
identified) and to say where (what file) it is (in). The reason it says
'in bugs.html' rather than 'bugs' (saying that the entry has bugs) is
because not all are bugs and it's saying where to see it anyway. But
some are features, others are missing links or files or other things
like that and to keep the same form it now says 'in bugs.html'.
This was done with my sgit(1) tool like:
sgit -e 's,\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs,\1/\2 in bugs.html,g' '*/*md'
The link to bugs.html itself has the path '../../bugs.html'. This is
important as it's meant to be rendered in the browser. At first this was
not remembered and I did something like:
sgit -e 's,\[\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs\](../../bugs.html,\[\1/\2 in bugs.html\](%%REPO_URL%%/bugs.html,g' '*/*md'
but this was changed to the simpler one due to the problem described
above. It's worth putting this note here as a reminder, though, so I
have included it here.
Tenth International Obfuscated C Code Contest
View the index.html web page for the given winning entry for information on how
on how to compile it 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.
Use make to compile entries. It is possible that on BSD or non-Unix
systems the Makefile needs to be changed. See the Makefiles and/or README.md
(that are used to build the index.html web page) files for details.
Read over the Makefile and/or README.md files for compile/build issues. Your
system may require certain changes (add or remove a library, add or remove a
#define i.e. the -D flag).
Name and address information are separated from the actual program prior to judging. This eliminates any chance that we would bias our judging for/against any person or group.
This year was the first year that ANSI C was the default. Use of classic K&R C was allowed so long as ANSI C compilers could still compile the entry. If you do not have an ANSI C compiler, you may not be able to compile the entry, sorry!
A few notes regarding future contests:
Be sure to wait until the 1994 rules are posted before submitting entries. Rules differ from year to year, sometimes in significant ways.
In 1994, we will retract the guideline that discouraged the use of C
constructs such as 3["curds"]. At one time, certain ANSI compilers did
not consider such expressions to be valid ANSI C. Alert readers noted
that the current ANSI standard considered them to be valid. We were
unable to find an ANSI C compiler that flagged such expressions as
errors.
Please send us comments and suggestions what we have expressed above. Also include anything else that you would like to see in future contests. Send such email to:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
If you use, distribute or publish these entries in some way, please drop us a line. We enjoy seeing who, where and how the contest is used.
Final Comments
IMPORTANT NOTE: The email addresses found above are for historical purposes only, and should not be used today. 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.
Credits:
We would like to thank Barbara Frezza for her role as official chef of the contest. Landon Curt Noll and Larry Bassel appreciated the opportunity to serve as official taste testers. And as usual, the food was excellent.