11th International Obfuscated C Code Contest Rules

Copyright (c) Landon Curt Noll & Larry Bassel, 1994.
All Rights Reserved.  Permission for personal, education or non-profit use is
granted provided this this copyright and notice are included in its entirety
and remains unaltered.  All other uses must receive prior permission in writing
from both Landon Curt Noll and Larry Bassel.

    Obfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
		b.  To darken.  2. To confuse:  his emotions obfuscated his
		judgment.  [LLat. obfuscare, to darken : ob(intensive) +
		Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
		obfuscatory adj.


GOALS OF THE CONTEST:

    * To write the most Obscure/Obfuscated C program under the rules below.
    * To show the importance of programming style, in an ironic way.
    * To stress C compilers with unusual code.
    * To illustrate some of the subtleties of the C language.
    * To provide a safe forum for poor C code.  :-)


NOTE: Changes from the original 1993 rules are denoted by change bars.  --->  |


RULES:

    To help us with the volume of entries, we ask that you follow these rules:

    1) Your entry must be a complete program.

    2) Your entry must be <= 3217 bytes in length.  The number of characters
       excluding whitespace (tab, space, newline), and excluding any ; { or }
       followed by either whitespace or end of file, must be <= 1536.

    3) Your entry must be submitted in the following format:

---entry---
rule:	1994
fix:	y or n   (n => this is a new entry, y => this replaces an older entry)
title:	title of entry  		    (see comments below)
entry:	Entry number from 0 to 7 inclusive  (your 1st entry should by 0)
date:	Date/time of submission in UTC	    (see comments below)
host:	Machine(s) and OS(s) under which your entry was tested
	Use tab indented lines if needed
---remark---
    Place remarks about this entry in this section.  It would be helpful if
    you were to indent your remarks with 4 spaces, though it is not a
    requirement.  Also, if possible, try to avoid going beyond the 79th
    column.  Blank lines are permitted.
---author---
name:	your name
org:	School/Company/Organization
addr:	postal address
	use tab indented lines to continue
	don't forget to include the country
email:  EMail address from a well known site or registered domain.
        If you give several forms, list them on separate tab indented lines.
anon:	y or n   (y => remain anonymous, n => ok to publish this info)
---info---
If your program needs an info file, place a uuencoded copy of it in
this section.  In the case of multiple info files, use multiple info
sections.  If your entry does not need a info file, skip this section.
---build---
Place a uuencoded copy of the command(s) used to compile/build your program
in this section.  It must uudecode into a file named 'build'.  The resulting
file must be 255 bytes or less.
---program---
Place a uuencoded copy of your program in this section.  It must uudecode
into a file named is 'prog.c'.  The resulting file must follow rule #2.
---end---

      Regarding the above format:

	* The title must match the expression: [a-zA-Z0-9_=][a-zA-Z0-9_=+-]*
	  and must be 1 to 12 characters in length.

	  It is suggested, but not required, that the title should
	  incorporate your username; in the case of multiple authors,
	  consider using parts of the usernames of the authors.

	* The date in the ---entry--- section should be given with respect
	  to UTC.  The format of the date should be as returned by asctime()
	  using the C locale.  (see guidelines for more info)

	* You may correct/revise a previously submitted entry by sending
	  it to the contest email address.  Be sure to set 'fix' in the
	  ---entry--- section to 'y'.  The corrected entry must use the same  |
	  title and entry number as submittion that is being corrected.  Be
	  sure that you note the resubmittion in the ---remark--- as well.

	* With the exception of the header, all text outside of the above
	  format may be ignored by the judges.  If you need tell the judges
	  something, put it in the ---remark--- section, or send a separate
	  EMail message to the judges.

	* Information from the ---author--- section will be published unless
	  'y' was given to the respective author's 'anon' line.

	* To credit multiple authors, include an ---author--- section for
	  each author.  Each should start with ---author--- line, and
	  should be found between the ---entry--- and ---build--- sections.

	* The entry's remarks should include:
	    - note if this entry is a re-submission of a previous entry.
	    - what this program does
	    - how to run the program (sample args or input)
	    - special compile or execution instructions, if any
	    - special filename requirements (see rule 4 and 5)
	    - information about any ---info--- files			      |
	    - why you think the program is obfuscated
	    - any other remarks (humorous or otherwise)

	* Do not rot13 your entry's remarks.  You may suggest that certain
	  portions of your remarks be rot13ed if your entry wins an award.

        * Info files should be used only to supplement your entry.  They
	  should not be required to exist.

	* If your entry does not need an info file, skip the ---info---       |
	  section.  If your entry needs multiple info files, use multiple
	  ---info--- sections, one per info file.  You should describe
	  each info file in the ---remark--- section.

	* Your sections must in the same order as in the above template.      |

    4) If your entry is selected as a winner, it will be modified as follows:

	   'build' is incorporated into a makefile, and 'build' is removed
	   'prog.c' is renamed to your entry's title, followed by an optional
	       digit, followed by '.c'
	   your entry is compiled into a file with the name of your entry's
	       title, possibly followed by a digit

       If your entry requires that a build file exist, state so in your
       entry's remark section.  The makefile will be arranged to execute a
       build shell script containing the 'build' information.  The name of
       this build shell script will be your entry's title, possibly followed
       by a digit, followed by '.sh'.

       If needed, your entry's remarks should indicate how your entry must
       be changed in order to deal with the new filenames.

    5) The build file, the source and the resulting executable should be
       treated as read-only files.  If your entry needs to modify these files,
       it should make and modify a copy of the appropriate file.  If this
       occurs, state so in your entry's remarks.

    6) Entries that cannot be compiled by an ANSI C compiler will be rejected.
       Use of common C (K&R + extensions) is permitted, as long as it does not
       cause compile errors for ANSI C compilers.

    7) The program must be of original work.  All programs must be in the
       public domain.  All copyrighted programs will be rejected.

    8) Entries must be received prior to 8-May-94 23:59 UTC.  (UTC is	      |
       essentially equivalent to Greenwich Mean Time)  EMail your entries to:

		...!{apple,pyramid,sun,uunet}!hoptoad!obfuscate
		obfuscate@toad.com

       We request that your message use the subject 'ioccc entry'.

       If possible, we request that you hold off on EMailing your entries
       until 4-Mar-94 12:00 UTC.  Early entries will be accepted, however.    |
       We will attempt to email a confirmation to the sender of any entry     |
       received after 4-Mar-94 12:00 UTC and before the close of the contest. |

    9) Each person may submit up to 8 entries per contest year.  Each entry
       must be sent in a separate EMail letter.

   10) Entries requiring human interaction to be built are not allowed.
       Making an entry must produce a file (or files) which may be executed.  |

   11) Programs that require special privileges (setuid, setgid, super-user,
       special owner or group) are not allowed.

   12) Legal abuse of the rules is somewhat encouraged.  An entry that, in    |
       the opinion of the judges, violates the rules will be disqualified.    |
       Entries that attempt to abuse the rules must try to justify why 	      |
       their rule abuse is legal in the ---remark--- section.		      |


FOR MORE INFORMATION:

    The Judging will be done by Landon Noll and Larry Bassel.  Please send
    questions or comments about the contest, to:

	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for  |
	judges@toad.com					 submitting entries)  |

    Comments about confusing rules and guidelines are also welcome.    	      |

    The rules and the guidelines may (and often do) change from year to
    year.  You should be sure you have the current rules and guidelines
    prior to submitting entries.  To obtain them, send EMail to the address   |
    above and use the subject 'send rules'.				      |

    One may obtain winners of previous contests (1984 to date), via ftp from: |

	host: ftp.uu.net	(192.48.96.9)				      |
	user: anonymous
	pass: yourname@yourhost
	dir:  pub/ioccc							      |

    As a last resort, previous winners may be obtained by sending EMail	      |
    to the above address.  Please use the subject 'send YEAR winners',	      |
    where YEAR is a single 4 digit year, a year range, or 'all'.	      |


chongo <Landon Curt Noll> /\cc/\  	chongo@toad.com
Larry Bassel			  	lab@sun.com
